Problem
The README and CONTRIBUTING point to Hostinger / Vercel / "any Node.js host" for deployment, but there's no first-class container path. Forkers who self-host on their own infra (a VPS, Coolify, Dokku, Kubernetes, etc.) currently have to write their own Dockerfile, figure out which env vars are build-time vs runtime for a Next.js standalone build, and get the non-root/standalone wiring right.
Proposal
Add an optional, self-contained container setup that changes nothing for existing users:
- A multi-stage
Dockerfile using Next.js output: "standalone" (deps -> build -> minimal runtime, runs as non-root).
- A single-service
docker-compose.yml (Supabase stays external — no DB container).
- A
.dockerignore.
docs/docker.md explaining the flow, and the important build-time (NEXT_PUBLIC_*, inlined at build) vs runtime (secrets via env_file) distinction.output: "standalone" in next.config.ts — a no-op for next start / Hostinger, only consumed by the Docker build.
This is purely additive: no dependency changes, no stack change, next start and the Hostinger path keep working exactly as before. Migrations are explicitly documented as out of scope for the container (applied via the Supabase CLI, matching the existing external-Supabase model).
I understand new features are intentionally kept narrow; opening this first per CONTRIBUTING to check alignment before sending the PR. Happy to close if it's out of scope for the template.
Problem
The README and CONTRIBUTING point to Hostinger / Vercel / "any Node.js host" for deployment, but there's no first-class container path. Forkers who self-host on their own infra (a VPS, Coolify, Dokku, Kubernetes, etc.) currently have to write their own Dockerfile, figure out which env vars are build-time vs runtime for a Next.js standalone build, and get the non-root/standalone wiring right.
Proposal
Add an optional, self-contained container setup that changes nothing for existing users:
Dockerfileusing Next.jsoutput: "standalone"(deps -> build -> minimal runtime, runs as non-root).docker-compose.yml(Supabase stays external — no DB container)..dockerignore.docs/docker.mdexplaining the flow, and the important build-time (NEXT_PUBLIC_*, inlined at build) vs runtime (secrets viaenv_file) distinction.output: "standalone"innext.config.ts— a no-op fornext start/ Hostinger, only consumed by the Docker build.This is purely additive: no dependency changes, no stack change,
next startand the Hostinger path keep working exactly as before. Migrations are explicitly documented as out of scope for the container (applied via the Supabase CLI, matching the existing external-Supabase model).I understand new features are intentionally kept narrow; opening this first per CONTRIBUTING to check alignment before sending the PR. Happy to close if it's out of scope for the template.