Ready to run under upaas on fsn1app1: prod branch, settings from env, health check, README section #59

Closed
opened 2026-09-25 11:02:24 +02:00 by clawbot · 1 comment
Collaborator

sneak's goal is six apps in beta under upaas (https://git.eeqj.de/sneak/upaas) on fsn1app1: webhooker and pixa first, then dnswatcher, netwatch and routewatch (his ruling of 24 September, sneak/project-management#1). This is netwatch's readiness issue; it starts after webhooker and pixa. Setting the app up in upaas and deploying it are sneak's.

It builds on #52: one Dockerfile, nginx serving the frontend and passing the backend's routes to it in the same container, and the DATA_DIR volume.

Definition of done

  • A prod branch exists, cut from main. It moves forward only through reviewed main to prod PRs (sneak's ruling of 30 August).
  • The image built from Dockerfile serves all of netwatch on one port and keeps its state under one volume path, which survives a restart.
  • Every setting comes from an environment variable; a value that is set but invalid stops the start.
  • The image has a HEALTHCHECK.
  • README.md has a short "Running under upaas" section listing exactly what the upaas app needs: the container port, the volume path, each environment variable with its value, and the health check.
  • Code changes land on next through reviewed PRs, with make check green.

Model: opus-5-5

sneak's goal is six apps in beta under upaas (https://git.eeqj.de/sneak/upaas) on fsn1app1: webhooker and pixa first, then dnswatcher, netwatch and routewatch (his ruling of 24 September, https://git.eeqj.de/sneak/project-management/issues/1). This is netwatch's readiness issue; it starts after webhooker and pixa. Setting the app up in upaas and deploying it are sneak's. It builds on https://git.eeqj.de/sneak/netwatch/issues/52: one `Dockerfile`, nginx serving the frontend and passing the backend's routes to it in the same container, and the `DATA_DIR` volume. ## Definition of done - A `prod` branch exists, cut from `main`. It moves forward only through reviewed `main` to `prod` PRs (sneak's ruling of 30 August). - The image built from `Dockerfile` serves all of netwatch on one port and keeps its state under one volume path, which survives a restart. - Every setting comes from an environment variable; a value that is set but invalid stops the start. - The image has a `HEALTHCHECK`. - `README.md` has a short "Running under upaas" section listing exactly what the upaas app needs: the container port, the volume path, each environment variable with its value, and the health check. - Code changes land on `next` through reviewed PRs, with `make check` green. Model: opus-5-5
clawbot self-assigned this 2026-09-25 11:02:24 +02:00
Author
Collaborator

Plan. prod is cut from main at fbfe1df; from here it moves only through reviewed main to prod PRs. clawbot cannot protect it; that request goes to sneak on the milestone PR #49.

Order, true dependencies only:

  1. #38 lands (root make check covers the backend).
  2. #52: the one image, nginx and the backend in one container, DATA_DIR under a VOLUME.
  3. #26: nginx listens on the port from PORT.
  4. This issue, one PR on top of those:
    • HEALTHCHECK in Dockerfile requesting /.well-known/healthcheck through nginx on the port from PORT, so it fails when either process is down.
    • Settings are checked at start: a set but invalid PORT, backend bind address or port, DEBUG, or TRUSTED_PROXIES entry stops the start with a message naming the variable. Today a bad PORT silently becomes 0.
    • The image starts on a fresh upaas volume: upaas bind-mounts a host directory it never creates, and the image's USER stands. If the directory needs an owner, the README's first-run steps say so.
    • README section "Running under upaas", next to the Docker section: the container port, the volume path and first-run steps, each environment variable with its value, and the health check (upaas fails a deploy that is not healthy 60 seconds after it starts).
    • Verified, not published: a missing volume directory, a root-owned one, and a correctly owned one that goes healthy within 60 seconds and keeps its reports across a restart; a bad PORT stops the start.

Model: opus-5-5

Plan. `prod` is cut from `main` at `fbfe1df`; from here it moves only through reviewed `main` to `prod` PRs. clawbot cannot protect it; that request goes to sneak on the milestone PR https://git.eeqj.de/sneak/netwatch/pulls/49. Order, true dependencies only: 1. https://git.eeqj.de/sneak/netwatch/pulls/38 lands (root `make check` covers the backend). 2. https://git.eeqj.de/sneak/netwatch/issues/52: the one image, nginx and the backend in one container, `DATA_DIR` under a `VOLUME`. 3. https://git.eeqj.de/sneak/netwatch/issues/26: nginx listens on the port from `PORT`. 4. This issue, one PR on top of those: - `HEALTHCHECK` in `Dockerfile` requesting `/.well-known/healthcheck` through nginx on the port from `PORT`, so it fails when either process is down. - Settings are checked at start: a set but invalid `PORT`, backend bind address or port, `DEBUG`, or `TRUSTED_PROXIES` entry stops the start with a message naming the variable. Today a bad `PORT` silently becomes 0. - The image starts on a fresh upaas volume: upaas bind-mounts a host directory it never creates, and the image's `USER` stands. If the directory needs an owner, the README's first-run steps say so. - README section "Running under upaas", next to the Docker section: the container port, the volume path and first-run steps, each environment variable with its value, and the health check (upaas fails a deploy that is not `healthy` 60 seconds after it starts). - Verified, not published: a missing volume directory, a root-owned one, and a correctly owned one that goes `healthy` within 60 seconds and keeps its reports across a restart; a bad `PORT` stops the start. 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/netwatch#59