Deploy production to the VPS #304

New issue

Closed

opened 2026-10-09 09:19:47 +00:00 by root · 10 comments

root commented

2026-10-09 09:19:47 +00:00

(Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#304, opened by @amaurycoudr on 2026-10-09 09:19 UTC.
Closed on GitHub on 2026-10-09 12:20 UTC as completed.

Parent

#303

What to build

https://chess.core-project.space serves the app from the VPS, deployed automatically once CI is green on main.

One image carries the built API and the front's build output and serves both from one origin, as the Render start command does today. GitHub Actions builds it and pushes it to GHCR, tagged with the commit SHA and a production tag. A deploy compose, parameterized by stack name, image tag and host, runs it as stack chess: one replica, restart unless stopped, on the shared proxy network with its Traefik router (host rule, websecure, the Let's Encrypt resolver), publishing no port. The shared Traefik compose that already runs on the VPS is versioned in the repo next to it.

The production workflow runs on CI's success on main, in a concurrency group that queues rather than cancels. It SSHes as deploy with the deploy key, pinning the VPS's host key, logs the VPS into GHCR with the job's short-lived token for the pull, logs out after, and brings the stack up with ORIGIN_ALLOWLIST set to the production origin.

Owner step: add the repo secrets the workflow names (deploy key, host, pinned host key).

Seam: Workflow post-conditions

Acceptance criteria

A merge to main with green CI deploys the image built for that commit, and no deploy runs on a red CI
Two quick merges deploy one after the other, never concurrently
The workflow ends by checking that stack chess runs exactly one container, that https://chess.core-project.space answers GET / with a valid certificate, that http:// redirects to HTTPS, and that no X-Robots-Tag: noindex header is present; any failed check fails the run, with the HTTPS check retrying within a bounded time for certificate issuance
A container that starts then exits fails the run
No registry credential remains on the VPS after a deploy
An unknown SSH host key fails the run
The Traefik compose in the repo matches what runs on the VPS, with how to apply it by hand documented next to it
Mutations from the production origin pass the origin guard (ADR 0028)

> _Imported from GitHub [amaurycoudr/chess-project#304](https://github.com/amaurycoudr/chess-project/issues/304), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-09 09:19 UTC._ > _Closed on GitHub on 2026-10-09 12:20 UTC as completed._  --- ## Parent #303 ## What to build `https://chess.core-project.space` serves the app from the VPS, deployed automatically once CI is green on `main`. One image carries the built API and the front's build output and serves both from one origin, as the Render start command does today. GitHub Actions builds it and pushes it to GHCR, tagged with the commit SHA and a production tag. A deploy compose, parameterized by stack name, image tag and host, runs it as stack `chess`: one replica, restart unless stopped, on the shared `proxy` network with its Traefik router (host rule, `websecure`, the Let's Encrypt resolver), publishing no port. The shared Traefik compose that already runs on the VPS is versioned in the repo next to it. The production workflow runs on CI's success on `main`, in a concurrency group that queues rather than cancels. It SSHes as `deploy` with the deploy key, pinning the VPS's host key, logs the VPS into GHCR with the job's short-lived token for the pull, logs out after, and brings the stack up with `ORIGIN_ALLOWLIST` set to the production origin. Owner step: add the repo secrets the workflow names (deploy key, host, pinned host key). Seam: Workflow post-conditions ## Acceptance criteria - [ ] A merge to `main` with green CI deploys the image built for that commit, and no deploy runs on a red CI - [ ] Two quick merges deploy one after the other, never concurrently - [ ] The workflow ends by checking that stack `chess` runs exactly one container, that `https://chess.core-project.space` answers `GET /` with a valid certificate, that `http://` redirects to HTTPS, and that no `X-Robots-Tag: noindex` header is present; any failed check fails the run, with the HTTPS check retrying within a bounded time for certificate issuance - [ ] A container that starts then exits fails the run - [ ] No registry credential remains on the VPS after a deploy - [ ] An unknown SSH host key fails the run - [ ] The Traefik compose in the repo matches what runs on the VPS, with how to apply it by hand documented next to it - [ ] Mutations from the production origin pass the origin guard (ADR 0028)

root commented

2026-10-09 09:19:47 +00:00

(Migrated from gitlab.core-project.space)

GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links).

Parent (sub-issue of): #303
Blocking: #310, #309, #306

> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._  - Parent (sub-issue of): #303 - Blocking: #310, #309, #306

root (Migrated from gitlab.core-project.space) closed this issue

2026-10-09 12:20:42 +00:00

root commented

2026-10-13 08:39:26 +00:00

(Migrated from gitlab.core-project.space)

mentioned in issue #306