Build and publish container images on push to main

[theNEXlevel]

Summary

Moves the production image build off the shared Coolify host and into GitHub Actions, mirroring the setup already running for C4G/metro-atlanta-saves.

• .github/workflows/publish.yaml (new) — on push to main (and workflow_dispatch): builds Dockerfile and Dockerfile.migrations, pushes :latest + :<sha> tags to ghcr.io/c4g/template-app and ghcr.io/c4g/template-migrations, then calls the Coolify deploy API.
• docker-compose.yml — the two application services now reference the published images and have no build: key. That absence is what stops Coolify from compiling on the server; it only pulls and restarts.
• docker-compose.build.yml (new) — restores the build: keys for local builds.
• .github/workflows/ci.yaml — PR runs overlay the build file, so they still verify an image built from the branch rather than the published :latest.
• README.md — documents the publish flow, the required secrets/variables, and what to change when copying the template.

Notes

• Deploy is triggered from the workflow rather than by Coolify's git webhook, so Coolify cannot pull :latest before the push has finished. Auto-deploy is already disabled on the Coolify app (is_auto_deploy_enabled = false), same as metro-atlanta-saves.
• The deploy step is guarded on both secrets.COOLIFY_TOKEN (org secret) and vars.COOLIFY_APP_UUID, so a copy of this template publishes images without redeploying the template's own application. The variable has been set on this repo to yg8wo0wc04gww0sog80gwww0 (confirmed via the Coolify API as the template app on C4G/template@main).
• NEXT_PUBLIC_VAPID_PUBLIC_KEY is passed as a build arg because Next.js inlines NEXT_PUBLIC_* at build time. BETTER_AUTH_URL is read at runtime by better-auth and stays a Coolify environment variable.

Follow-up required after the first run

The two new GHCR packages are created private. The Coolify host pulls anonymously (no ~/.docker/config.json on the server), so both packages must be set to public — matching the existing ghcr.io/c4g/metro-atlanta-saves-* and ghcr.io/c4g/va-dat packages — or the first deploy will fail to pull.

🤖 Generated with Claude Code

[theNEXlevel]

Follow-up: one image, many environments

Pushed 4b48724 so a test environment can be added later without repository changes.

As originally written this PR baked NEXT_PUBLIC_VAPID_PUBLIC_KEY into the image as a build arg, which tied a published build to one environment — standing up a test app later would have needed a second image built with that environment's VAPID key.

The Dockerfile now passes no build args at all. Next.js substitutes a NEXT_PUBLIC_* variable into the bundle only when it is present at build time, so leaving it unset keeps the expression as a real runtime lookup, and docker-compose.yml already passes the value at runtime.

Verified against the compiled output of src/lib/web-push.ts (Next 16.1.6 / Turbopack), same module in both builds:

Build	Compiled form
var unset	let r=process.env.NEXT_PUBLIC_VAPID_PUBLIC_KEY — runtime lookup
var set	let r="BTestKeyAAA111" — baked literal

This is safe because the key is read server-side only (src/lib/web-push.ts); the browser fetches it from GET /api/notifications/subscribe (src/hooks/use-push-notifications.ts:93) rather than reading an inlined copy. The Dockerfile records that constraint, since baking a value back in to serve client code would re-tie the image to a single environment.

BETTER_AUTH_URL is dropped too — it was set on the builder stage, which the runner stage does not inherit, so it never reached the running app.

Consequences

• Adding a test environment is now just a second Coolify application pointed at this same compose file. IMAGE_TAG selects the build: unset tracks latest, or pin a commit SHA to promote something already verified.
• The publish workflow needs no application secrets to build. NEXT_PUBLIC_VAPID_PUBLIC_KEY is no longer required as a GitHub secret; it stays a Coolify runtime variable. The required-configuration table in the README is updated accordingly.

[theNEXlevel]

Follow-up: one image for both services

Pushed d6c0767. Dockerfile.migrations is deleted; template-migrations now runs the same image as the app with a different command.

Why

Image	Size
template-app	358 MB
template-migrations	1.63 GB
...migrations actually carried	94 kB

Dockerfile.migrations ran pnpm install --prod — pulling Next, React, ag-grid, better-auth and everything else — then added the Prisma CLI, in one un-pruned 1.11 GB layer, to run a single prisma migrate deploy.

After

template-migrations:
  image: ghcr.io/c4g/template:${IMAGE_TAG:-latest}
  command: ['node', '/node_modules/prisma/build/index.js', 'migrate', 'deploy']

Per deploy: ~2 GB across two images → 685 MB in one, and two GHCR packages → one. The ordering guarantee is unchanged; the app still waits on service_completed_successfully. The image is renamed ghcr.io/c4g/template (dropping the now-meaningless -app suffix) — nothing is published yet, so this costs nothing.

Two load-bearing details

Both were found by building, not by reasoning:

1. The migrator stage installs with npm, not pnpm — pnpm's symlink farm points into .pnpm/ and does not survive a COPY between stages.
2. It lands at /node_modules, not /app/node_modules. The first attempt merged into the standalone tree and failed outright:

   cannot copy to non-directory: .../app/node_modules/react
   

   Next's standalone output contains symlinked packages. /node_modules is the last place Node looks when resolving from /app, so prisma.config.ts still finds dotenv and prisma/config while the app's own resolution is untouched.

Verified locally against the real stack

• All 4 migrations applied, migration container exited 0, app came up healthy — so prisma.config.ts resolved correctly (the prisma/migrations path comes from that file).
• GET /api/health → 200.
• GET /api/notifications/subscribe → {"publicKey":"BTestKey"} — the value passed as a runtime env var to an image built with no build args. That is the "one image, many environments" change from 4b48724 confirmed end-to-end in a real container, not just in a bundle grep.

One thing I could not improve

252 MB of the image is the Prisma CLI tree, mostly @prisma/studio-core and its UI stack (effect, @electric-sql, react-dom, elkjs). I tested removing it — the CLI eagerly requires effect at startup and fails with Cannot find module 'effect', so it is not safely prunable. Left alone rather than shipping fragile deletions into a template; worth revisiting if Prisma ever splits the CLI.