Coolify
Deploy the node target to Coolify, a self-hosted PaaS that runs the standard Docker build on your own VPS.
Coolify is a self-hosted PaaS you run on your own VPS. It deploys the node target's standard node:24-alpine Docker build - the boilerplate has no Coolify-specific code, so this is a guide for running that artifact, not a dedicated integration.
Deploy
Install Coolify on a fresh VPS (Ubuntu/Debian recommended):
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bashThen open the dashboard at http://<your-server-ip>:8000 and finish onboarding.
Add your server. The host Coolify runs on is registered as localhost automatically. To deploy to a different machine, add it under Servers with SSH key access.
Create a resource from your Git repository. Choose Dockerfile as the build pack and point it at the owner app's Dockerfile - the frontend app's (EXPOSE 3000) for fullstack, or apps/backend/Dockerfile (EXPOSE 3010) for separate. The build is the standard multi-stage node:24-alpine image; set the resource's exposed port to match.
Set environment variables on the resource (see the table below). DATABASE_URL is required because the CMD-time schema step reads it on boot.
Deploy. Coolify builds the image and starts the container with CMD pnpm start. The CLI prepends pnpm -F @repo/database migrate to that start script (packages/cli/src/generators/deploy-scripts.ts), so the schema migrates on every container start before the server boots.
Attach a domain + TLS. Add your domain under the resource's Domains field. Coolify provisions a Let's Encrypt certificate and routes traffic through its built-in proxy automatically.
Bring your own database and cache
In production you supply the database and cache - Coolify never reads infra/docker-compose.yml (that file is local-development only). Use a managed provider, or run Postgres and Redis as separate Coolify resources, then point these env vars at them.
| Variable | Required | Source |
|---|---|---|
DATABASE_URL | Yes | Self-hosted Postgres, Neon, or Supabase - see Database |
REDIS_URL | Yes | Self-hosted Redis (or a Coolify Redis resource) - see Caching |
BETTER_AUTH_SECRET | Yes | Random string, min 32 chars |
API_URL | Yes | Public URL the backend is reachable at |
INNGEST_APP_ID, INNGEST_EVENT_KEY, INNGEST_BASE_URL | Yes | Background jobs - see Background jobs |
BASE_URL, TRUSTED_ORIGINS | Recommended | Production URL + allowed origins |
See Environment variables for the full list. Self-hosted Redis is fully supported on a long-running host like Coolify - the serverless-only Upstash requirement does not apply here.
Never pass --demo for a real deployment - the schema step becomes a destructive reset && push --force that wipes the database on every container start.
pnpm infra / infra/docker-compose.yml (Postgres, Redis, Inngest, plus Mailpit only when the email provider is smtp) are local-development only - not a deployment step. In production every dependency is a real managed or self-hosted service wired in through the env vars above.
Next steps
Self-hosting with Docker
The node target image, multi-stage build, and migrate-on-boot details.
Separate backend
Run the standalone Hono server on API_PORT for independent scaling.
Reverse proxy
Front the apps by host and path if you route outside Coolify's proxy.
Going to production
The pre-launch checklist of secrets, flags, and webhooks.