Add Portabase for containerized DB backups

[MrModest]

What

Adds Portabase — a containerized PostgreSQL backup tool (dashboard + Rust agent) — as a new deploy_portabase role, taking over the job that bare-metal Cronicle currently does (pg_dumpall via docker exec, on a schedule).

Both systems keep running in parallel. Nothing here retires or disables Cronicle.

Spec: docs/superpowers/specs/2026-09-20-portabase-db-backups-design.md
Plan: docs/superpowers/plans/2026-09-23-portabase-db-backups.md

Why

Every Cronicle job on the server was the same alias, d-db-dump <app> <pg container>. Keeping a bare-metal Node.js install (and the NodeSource apt repo) on the host purely to schedule database dumps is the cost being removed. Portabase does that specific job — scheduled dumps, retention, restore, a UI — as containers.

How it connects to the databases

The agent is a plain PostgreSQL client: it runs pg_dump --host <container> --port 5432. So it needs network reachability, not a docker socket.

Rather than reusing nginxnetwork (today every service in every app joins it — a known over-exposure to fix separately), this adds a dedicated db_backup network created with internal: true, so it has no route off the host. Each app's PostgreSQL service opts in explicitly; application containers are untouched.

Because a compose service that declares networks: stops implicitly joining default, every DB service lists both — verified across all ten files (90 insertions, 0 deletions).

Changes

Area	Change
setup_docker	creates the db_backup network, internal: true
10 app roles	PostgreSQL service joins db_backup, keeps default
deploy_portabase	new role: dashboard + its own PostgreSQL + agent
main.yml, vars/apps.yml	role import and proxy entry
init_setup	isu_cronicle_enabled flag, defaults true

Dumps land at /mnt/pools/slow/backups/portabase/private/uploads/. Cronicle's db_dumps/ tree is untouched.

Notes for review

• The agent has no docker socket and is not on nginxnetwork.
• portabase-app deliberately has no user: pin, unlike portabase-pg: the upstream image's prod stage ends with USER root and its entrypoint execs nginx without dropping privileges. There's a comment in the compose file recording this.
• PRIVATE_PATH is left at the image default /data/private — the entrypoint hardcodes mkdir -p /data/private/uploads/tmp for tusd, so overriding it would split the storage layout in two.
• Immich uses ghcr.io/immich-app/postgres (VectorChord): pg_dump works, but restoring needs an image carrying the same extension. Documented in the role README.

Not done in this PR

• The v_portabase vault block (secrets — added out of band).
• Deployment and bootstrap. EDGE_KEY is minted by the dashboard, so first deploy is two-phase; the runbook is in roles/deploy_portabase/README.md.
• A restore drill. Nothing here should be trusted as a backup until one dump has been restored by hand.

🤖 Generated with Claude Code

[MrModest]

Closing without merging — not adopting Portabase.

The implementation here is complete and reviewed, and the design questions it raised (dedicated internal network instead of nginxnetwork, no docker socket on the agent) all worked out. What changed is the assessment of the dependency itself:

• Rootless is not available and has no date. Rootless / non-root Docker images and split tusd/nginx out of the all-in-one container for Kubernetes PSA compliance Portabase/portabase#451 documents that the production image is root by design: it bundles Next.js, PostgreSQL, tusd and nginx in one container, with nginx binding port 80 from a config baked into the image. There is no env var to change the port — overriding it means shipping our own nginx config against an image we do not control. The draft PR that would fix it (feat: harden the container image and helm chart Portabase/portabase#453) is a community contribution that has been stalled with conflicts since early August.
• The agent stages dumps inside the container. Where do portabase agent store its temporary zipfile (while using docker volumes) ? and is this directory changeable ? Portabase/portabase#387: temp files default to the container's /tmp, which on this host is the writable layer under /var/lib/docker on the root ext4 disk, not a pool. Backing up a large database would need a TMPDIR override plus a scratch mount to avoid filling the root filesystem.

Neither is fatal on its own, and both have workarounds. But together they amount to carrying local patches against upstream's assumptions for a service whose entire job is to be boringly reliable — and the thing it would replace is not broken. Cronicle now runs v0.9.134 on Node.js 24 after the NodeSource nodistro repository fix, so the DB dumps keep working as they are.

Nothing from this branch is merged. The db_backup network and the ten application compose edits existed only to serve Portabase, so they are dropped with it rather than left as unused configuration.

The spec and plan (docs/superpowers/specs/2026-09-20-portabase-db-backups-design.md, docs/superpowers/plans/2026-09-23-portabase-db-backups.md) stay on this branch as a record of the evaluation.