CI (build/deploy) и рантайм самого бэкенда (провижининг новых нод через
NodeService::provision_node_via_ssh — раньше читал GHCR_TOKEN, теперь
GITEA_REGISTRY_TOKEN) теперь используют gitea.netrunner-vpn.com вместо
ghcr.io. .github/workflows остались нетронутыми — та копия для настоящего
GitHub CI, там ghcr.io уместен и дальше (свой GITHUB_TOKEN, не наш секрет).
Telegram Login Widget в браузере требует именно порт 443 — его CSP
frame-ancestors от oauth.telegram.org не учитывает порт домена и всегда
подразумевает дефолтный порт схемы, поэтому на 8443 виджет рендерился, но
iframe блокировался как cross-origin. VPN-нода, ранее занимавшая 443 на
dev VPS, перенесена на другой порт, так что конфликта больше нет.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous deploy attempt confirmed the failure mode directly: `docker
compose build caddy` over SSH got most of the way through compiling
xcaddy (downloading Go modules) and then the whole SSH command hit
appleboy/ssh-action's timeout mid-build, aborting the deploy before it
ever reached `up -d`. Compiling anything on that VPS was already a
deliberate anti-pattern here — see DEPLOYMENT.md's "compilation happens
in GitHub Actions, never on the VPS" — this just hadn't been applied to
the new Caddy service yet.
Added a build-caddy job to build.yml pushing
ghcr.io/nineap/netrunner-caddy-cloudflare:latest (hardcoded lowercase
owner — github.repository_owner resolves to "nineAp" and Docker rejects
mixed-case image refs, same fix already applied to the main image's
deploy script). docker-compose.dev-remote.yml now just pulls that image;
deploy.yml no longer builds it over SSH or ships Dockerfile.caddy to the
server at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bot buttons that open a Web App (Личный Кабинет/Тарифы/Синдикат) appeared
to load and then silently do nothing on the dev stand. Root cause:
teloxide's WebAppInfo::url (and the underlying Bot API) requires an HTTPS
URL — Telegram's client refuses to render a Web App served over plain
HTTP, with no error surfaced to the user, just a stuck loading state.
WEB_APP_BASE_URL was http://dev.netrunner-vpn.com:8080.
Port 443 on the dev VPS is already in use by a VPN node, and port 80 is
closed, so a normal HTTP-01 ACME challenge won't work. Added a custom
Caddy build (caddy-dns/cloudflare) terminating TLS via DNS-01 on port
8443 instead, reverse-proxying to the existing plain-HTTP app container.
WEB_APP_BASE_URL and the CORS/CSRF allowlists now point at the :8443
origin, and COOKIE_SECURE reverts to true (the default, matching prod) —
now that the backend actually has real TLS to serve it over, we no
longer need the plain-HTTP workaround introduced for the earlier
cookie-drop bug. Verified the custom image builds and the Caddyfile
validates (only the dummy Cloudflare token used for the local test is
rejected, as expected).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Add slim docker-compose.dev-remote.yml (app+db+redis, no monitoring)
for the remote dev VPS, and a deploy-dev job that auto-runs after a
successful image build on main. Bump Dockerfile.dev's Rust image so
edition2024 dependencies build. Stop tracking .env.dev (real secrets
were committed) in favor of .env.dev.example / .env.dev-remote.example
templates.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
nineap