Evil0ctal 121940fdfa ci: publish from a release branch, and say what size machine this needs ...

Two things a first real deployment made obvious.

**Sizing.** The docs had a resource table but never answered "what
machine is this written for". The ceilings add up to about 8 GiB and
browser-rpc asks for 4 CPUs, so the answer is a 4 vCPU / 8 GiB box —
now stated, along with the two smaller sizes that work and what each
costs you. The minimum row is measured on the demo VPS rather than
guessed: 2 vCPU / 3.8 GiB, whole stack with the browser on, idle at
1.0 GiB and peaking at 1.1 GiB during a mint, with browser-rpc going
234 MiB → 845 MiB. The peak is what sets the floor, which is why the
swap advice is there rather than being about "performance".

Also the failure that is not a slowdown: `cpus: 4.0` on a two-core host
makes Docker refuse to start the container outright. Documented with the
override-file shape, because editing compose.yml to fit one machine is
how a repository stops describing a normal one.

**Publishing.** docker-publish.yml watched `main`, so every merge spent
several minutes of buildx and QEMU, and moved `latest` onto whatever was
pushed a few minutes ago — anyone following the README pulled work in
progress. It now watches `release` and `v*` tags. `main` is still fully
tested on every push by ci.yml; what became deliberate is publishing:

    git push origin main:release

`latest` follows `release` for the same reason it used to follow the
default branch: it should name a build somebody decided to make.

(For the record, the free-minutes worry does not apply — this repository
is public, and Actions minutes are unmetered for public repositories.
The reasons above stand on their own.)

2026-09-10 06:53:47 -07:00

..

ci.yml

ci: point the workflows at main, now that the rename is done

2026-09-10 04:45:47 -07:00

docker-publish.yml

ci: publish from a release branch, and say what size machine this needs

2026-09-10 06:53:47 -07:00