The Drizzle Gateway browses every stack through an SSH tunnel #370

New issue

Closed

opened 2026-10-11 16:26:10 +00:00 by root · 8 comments

root commented

2026-10-11 16:26:10 +00:00

(Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#370, opened by @amaurycoudr on 2026-10-11 16:26 UTC.

Parent

#354

What to build

Stories 14–17 of #354. First, read the licence terms of the Gateway version to be pinned and record them in the PR. If they do not allow this use, ship without the Gateway: point the owner at drizzle-kit studio through the same tunnel, and say so on #346.

The migrate entry point ensures the Gateway role on every stack, idempotently:

it creates the role if it is missing and sets its password from the stack's secret;
it grants row privileges on the app role's tables, plus default privileges so future tables follow;
no password goes into committed SQL, and no init script is mounted.

Production's Gateway password is a GitHub secret, delivered like the app role's; a preview's is a throwaway value in the preview overlay.

The Gateway runs as its own Compose project on the VPS, applied by hand like the proxy:

its image pinned to an exact version and its port published on the loopback only;
a volume for its saved connections, and its master password set at apply time, never committed;
a README with a "check it matches" command and the command that reattaches every running stack after the Gateway is recreated.

The up script connects the Gateway to the stack's internal network after the app is up. It does so idempotently, and warns without failing when the Gateway is not running. The removal script disconnects it before tearing the stack down; the cap and the reaper inherit this. The owner adds connections in the Gateway's UI by the stack's database host name.

Add the Gateway apply and its secrets to the owner wizard. See #354, Drizzle Gateway and Roles and secrets.

Seam: the deploy verification scripts, run by the workflows against the VPS.

Acceptance criteria

The PR records the pinned version's licence terms and whether they allow this use.
After a deploy, the verify script finds the Gateway (when running) on the stack's internal network.
The Gateway role can read and write a row but cannot create, alter or drop a table; the verify script checks that it can read and cannot create a table.
Ensuring the role on an already-migrated database changes nothing.
Deploying a preview while the Gateway is stopped succeeds with a warning.
Removing a stack the Gateway joined leaves nothing behind; the removal verification passes.
The Gateway's port is bound to the VPS loopback only, and the check command reports a match.
The gate is green.

> _Imported from GitHub [amaurycoudr/chess-project#370](https://github.com/amaurycoudr/chess-project/issues/370), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-11 16:26 UTC._  --- ## Parent #354 ## What to build Stories 14–17 of #354. First, read the licence terms of the Gateway version to be pinned and record them in the PR. If they do not allow this use, ship without the Gateway: point the owner at `drizzle-kit studio` through the same tunnel, and say so on #346. The migrate entry point ensures the Gateway role on every stack, idempotently: - it creates the role if it is missing and sets its password from the stack's secret; - it grants row privileges on the app role's tables, plus default privileges so future tables follow; - no password goes into committed SQL, and no init script is mounted. Production's Gateway password is a GitHub secret, delivered like the app role's; a preview's is a throwaway value in the preview overlay. The Gateway runs as its own Compose project on the VPS, applied by hand like the proxy: - its image pinned to an exact version and its port published on the loopback only; - a volume for its saved connections, and its master password set at apply time, never committed; - a README with a "check it matches" command and the command that reattaches every running stack after the Gateway is recreated. The up script connects the Gateway to the stack's internal network after the app is up. It does so idempotently, and warns without failing when the Gateway is not running. The removal script disconnects it before tearing the stack down; the cap and the reaper inherit this. The owner adds connections in the Gateway's UI by the stack's database host name. Add the Gateway apply and its secrets to the owner wizard. See #354, *Drizzle Gateway* and *Roles and secrets*. Seam: the deploy verification scripts, run by the workflows against the VPS. ## Acceptance criteria - [ ] The PR records the pinned version's licence terms and whether they allow this use. - [ ] After a deploy, the verify script finds the Gateway (when running) on the stack's internal network. - [ ] The Gateway role can read and write a row but cannot create, alter or drop a table; the verify script checks that it can read and cannot create a table. - [ ] Ensuring the role on an already-migrated database changes nothing. - [ ] Deploying a preview while the Gateway is stopped succeeds with a warning. - [ ] Removing a stack the Gateway joined leaves nothing behind; the removal verification passes. - [ ] The Gateway's port is bound to the VPS loopback only, and the check command reports a match. - [ ] The gate is green.

root commented

2026-10-11 16:26:10 +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): #354
Blocked by: #369
Blocking: #372

> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._  - Parent (sub-issue of): #354 - Blocked by: #369 - Blocking: #372

root commented

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

(Migrated from gitlab.core-project.space)

mentioned in issue #372