IP control-plane сервера сам по себе не секрет (не даёт доступа), просто
не хочется палить его без причины — vars в приватном репо видны так же,
как код, но не маскируются в логах и не write-only, как secrets.
Настоящие секреты (SSH-ключи, GHCR_TOKEN) не тронуты.
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>
github.repository_owner resolves to "nineAp" (mixed case), which Docker
rejects as an invalid repository reference — hardcode the lowercase
"nineap" used by the GHCR package and the compose files' image default.
Also apply the same secrets-interpolation fix from the dev job to
deploy-prod so a future manual prod deploy doesn't hit the same
"password is empty" failure from unforwarded SSH env vars.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
appleboy/ssh-action's envs: mechanism forwards vars via SSH SendEnv,
which sshd silently drops unless AcceptEnv is configured server-side.
On the freshly bootstrapped dev VPS that left GHCR_TOKEN empty on the
remote end, so `docker login --password-stdin` failed with "password
is empty" even though the SSH connection itself was fine. Interpolate
the secret directly into the script text instead.
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
Kirill