Свой netrunner-landing/netrunner-landing-proxy теперь на
gitea.netrunner-vpn.com. Сторонний образ PocketBase (ghcr.io/muchobien/
pocketbase) не трогаю — это чужой образ, живёт там же, где и жил.
netrunner-backend dev теперь проксирует Caddy на стандартный порт 443
(VPN-нода, ранее занимавшая его, перенесена на другой порт) — Telegram
Login Widget в браузере требует именно этот порт.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
netrunner-backend's dev stand now terminates TLS via Caddy on :8443
(needed for Telegram Web Apps, which require https://, and its session
cookies are Secure again to match prod). Updated ACCOUNT_ORIGIN/API_URL
here to match — a plain-HTTP fetch to :8080 would no longer receive a
cookie the browser is willing to store.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Telegram Login Widget refuses to run on a raw IP ("Bot domain invalid")
— BotFather's /setdomain only accepts an actual domain name. Switched
every browser-facing URL in the dev compose (ACCOUNT_ORIGIN, API_URL,
PB_PUBLIC_URL, NEXT_PUBLIC_*) to dev.netrunner-vpn.com, which needs a DNS
A-record pointing at 45.76.161.137.
Also dropped the silent BOT_USERNAME fallback to the prod bot's handle —
that fallback is exactly how this surfaced: a prod bot has the prod
domain registered in BotFather, so serving its widget from the dev host
was guaranteed to fail. BOT_USERNAME is now a required env var with a
loud error instead of a quiet wrong default.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auth: drop localStorage session token entirely, talk to netrunner-backend
via credentials:"include" HttpOnly cookies shared over the common parent
domain, and redirect to the account subdomain (ЛК) after login instead of
a dead local /profile route.
Config: NEXT_PUBLIC_* values used by client components (API_URL,
ACCOUNT_ORIGIN, BOT_USERNAME, PB_URL) get inlined into the JS bundle at
image build time and can't be overridden by docker-compose environment at
container start. Moved these reads into server components (page.tsx) and
thread them down as props, so one built image can genuinely serve both
prod and dev by config alone.
CI/CD: split the old single auto-deploy-to-prod workflow into build.yml
(build+push on every push to main) and deploy.yml with deploy-dev (auto,
same VPS as netrunner-backend's dev environment) and deploy-prod (manual
dispatch only) — mirrors netrunner-backend's pipeline shape. Added
docker-compose.dev-remote.yml pointing at the dev backend.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
nineap