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

Open
opened 2026-08-07 18:41:17 +02:00 by clawbot · 2 comments
Collaborator

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
Author
Collaborator

What the homoicon rehearsal (#213) shows you should do on fsn1app1:

  • Before the first deploy, create the host directory for homoicon's volume and make it owned by uid 1000. upaas does not create it.
  • Set BASE_DOMAIN to the real host before the first deploy. homoicon reads it only on its first start, so changing it in upaas later does nothing (sneak/homoicon#1380).
  • Copy the root password from the container log in upaas right after the first deploy, before any push or redeploy. The next deploy replaces the container and the line is gone. If you miss it, hi passwd inside the container resets it.
  • Don't add a port mapping for homoicon in upaas: it publishes on every interface, over plain HTTP. Set the app's Docker network to the network your proxy is on and point the proxy at upaas-homoicon:8080. The rehearsal checked that this works.
  • homoicon must be reached over HTTPS through the proxy, with the Host header passed through. Its sign-in cookies are HTTPS-only, so sign-in fails over plain HTTP.
  • Publish upaas's own port on 127.0.0.1 (the README example publishes 8080 on every interface), and leave UPAAS_PLAINTEXT_HTTP unset behind the TLS proxy.
  • Until #215 and #216 are fixed, every deploy leaves a Docker volume and old images behind, so watch disk space. Recreating the upaas container breaks older deployment log downloads (#214).

Model: opus-5-5

What the homoicon rehearsal (https://git.eeqj.de/sneak/upaas/issues/213) shows you should do on fsn1app1: - Before the first deploy, create the host directory for homoicon's volume and make it owned by uid `1000`. upaas does not create it. - Set `BASE_DOMAIN` to the real host before the first deploy. homoicon reads it only on its first start, so changing it in upaas later does nothing (https://git.eeqj.de/sneak/homoicon/issues/1380). - Copy the root password from the container log in upaas right after the first deploy, before any push or redeploy. The next deploy replaces the container and the line is gone. If you miss it, `hi passwd` inside the container resets it. - Don't add a port mapping for homoicon in upaas: it publishes on every interface, over plain HTTP. Set the app's Docker network to the network your proxy is on and point the proxy at `upaas-homoicon:8080`. The rehearsal checked that this works. - homoicon must be reached over HTTPS through the proxy, with the Host header passed through. Its sign-in cookies are HTTPS-only, so sign-in fails over plain HTTP. - Publish upaas's own port on `127.0.0.1` (the README example publishes `8080` on every interface), and leave `UPAAS_PLAINTEXT_HTTP` unset behind the TLS proxy. - Until https://git.eeqj.de/sneak/upaas/issues/215 and https://git.eeqj.de/sneak/upaas/issues/216 are fixed, every deploy leaves a Docker volume and old images behind, so watch disk space. Recreating the upaas container breaks older deployment log downloads (https://git.eeqj.de/sneak/upaas/issues/214). Model: opus-5-5
Author
Collaborator

One addition from the fixes that followed the rehearsal (#221, on next2): upaas now builds apps with BuildKit, whose build cache Docker limits by itself only from Docker Engine 28.2. If fsn1app1 runs an older Docker, add "builder": {"gc": {"enabled": true}} to /etc/docker/daemon.json and restart Docker, or the build cache grows with every deploy.

Model: opus-5-5

One addition from the fixes that followed the rehearsal (https://git.eeqj.de/sneak/upaas/pulls/221, on `next2`): upaas now builds apps with BuildKit, whose build cache Docker limits by itself only from Docker Engine 28.2. If fsn1app1 runs an older Docker, add `"builder": {"gc": {"enabled": true}}` to `/etc/docker/daemon.json` and restart Docker, or the build cache grows with every deploy. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/upaas#181