Deploy µPaaS to fsn1app1 and verify end-to-end #181

New Issue

clawbot · 2026-08-07T18:41:17+02:00

clawbot commented

2026-08-07 18:41:17 +02:00

Deploy the current release candidate to fsn1app1 and prove the full
webhook → build → deploy loop works in production. Requires server
access, so this one is assigned to @sneak.

Steps (per the README Docker Compose section):

pull/checkout the release candidate on fsn1app1 and run
docker compose up -d with HOST_DATA_DIR set to an absolute
host path (relative paths break bind mounts during builds)
put the service behind the TLS-terminating reverse proxy; the app
itself listens plain HTTP on PORT (default 8080)
complete first-run setup (single admin user)
create a test app: repo on git.eeqj.de, deploy key installed from
the generated per-app keypair, webhook URL configured in Gitea,
branch filter set
push a commit to the configured branch and watch the deploy: webhook
received, repo cloned via deploy key, image built with live build
log streaming, old container replaced, new container running
exercise the ops surface: container start/stop/restart, container
logs, deploy log download
if ntfy/Slack notifications are configured, confirm a deploy
notification arrives

Definition of done:

upaas running on fsn1app1, reachable over HTTPS via the proxy
one real app auto-deploys from a git push, verified twice in a row
container controls and logs work from the UI
any bugs found are filed as new issues on this repo (not fixed
ad-hoc on the server)
outcome recorded in a comment here, including the deployed commit
hash

Deploy the current release candidate to fsn1app1 and prove the full webhook → build → deploy loop works in production. Requires server access, so this one is assigned to @sneak. Steps (per the README Docker Compose section): - pull/checkout the release candidate on fsn1app1 and run `docker compose up -d` with `HOST_DATA_DIR` set to an **absolute** host path (relative paths break bind mounts during builds) - put the service behind the TLS-terminating reverse proxy; the app itself listens plain HTTP on `PORT` (default 8080) - complete first-run setup (single admin user) - create a test app: repo on git.eeqj.de, deploy key installed from the generated per-app keypair, webhook URL configured in Gitea, branch filter set - push a commit to the configured branch and watch the deploy: webhook received, repo cloned via deploy key, image built with live build log streaming, old container replaced, new container running - exercise the ops surface: container start/stop/restart, container logs, deploy log download - if ntfy/Slack notifications are configured, confirm a deploy notification arrives Definition of done: - upaas running on fsn1app1, reachable over HTTPS via the proxy - one real app auto-deploys from a git push, verified twice in a row - container controls and logs work from the UI - any bugs found are filed as new issues on this repo (not fixed ad-hoc on the server) - outcome recorded in a comment here, including the deployed commit hash

clawbot added this to the 1.1.0 milestone 2026-08-07 18:41:17 +02:00

sneak was assigned by clawbot

2026-08-07 18:41:17 +02:00

clawbot referenced this issue

2026-08-07 18:41:25 +02:00

Tag and publish release 1.1.0 #182

clawbot referenced this issue

2026-09-03 18:29:27 +02:00

Tag and publish release 1.1.0 #182

clawbot commented

2026-09-03 18:29:56 +02:00

Release-candidate status for this deploy, as of 2026-09-03:

main @ 7a34fc9 is green — full docker build . passes end to end (exit 0): make fmt-check, make lint (0 issues. under the pinned golangci-lint v2.12.2), make test, and the binary build. That is a valid RC commit to deploy.

Two caveats worth carrying to the server, neither of which blocks the deploy itself:

#185 — static/js/alpine.min.js on main is not actually minified (94.8 KB vs 45.7 KB upstream; it was expanded by a stray prettier pass in 594537e). The dashboard will work, it just serves ~49 KB more than it should. Worth knowing when judging page-load behaviour during the verification.
#177 — the deploy-log download handler still has no path-containment check; the gosec finding was suppressed rather than fixed. The log-download step in the ops-surface checklist above touches exactly this code path.

This issue stays with you — it needs server access, and no agent will deploy autonomously. Reminder from the description: file any bugs found as new issues here rather than patching on the server.

Release-candidate status for this deploy, as of 2026-09-03: `main` @ `7a34fc9` is **green** — full `docker build .` passes end to end (exit 0): `make fmt-check`, `make lint` (`0 issues.` under the pinned golangci-lint v2.12.2), `make test`, and the binary build. That is a valid RC commit to deploy. Two caveats worth carrying to the server, neither of which blocks the deploy itself: - [#185](https://git.eeqj.de/sneak/upaas/issues/185) — `static/js/alpine.min.js` on `main` is not actually minified (94.8 KB vs 45.7 KB upstream; it was expanded by a stray prettier pass in `594537e`). The dashboard will work, it just serves ~49 KB more than it should. Worth knowing when judging page-load behaviour during the verification. - [#177](https://git.eeqj.de/sneak/upaas/issues/177) — the deploy-log download handler still has no path-containment check; the gosec finding was suppressed rather than fixed. The log-download step in the ops-surface checklist above touches exactly this code path. This issue stays with you — it needs server access, and no agent will deploy autonomously. Reminder from the description: file any bugs found as new issues here rather than patching on the server.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/upaas#181