Deploy
Git-connected deployments with per-branch previews, an approval gate before production, and one-click rollback.
On this page
PrimDB deploys are git-connected through GitHub. Every push to any branch can create a preview deployment; production is protected by an approval gate you control per project.
What you can deploy
If your repo has a Dockerfile, PrimDB builds it and the table below does not apply — anything you can containerise runs. With no Dockerfile, the build is detected automatically. These are the stacks we checked against the builder we actually run, and what each one needs from you.
| Stack | Detected from | What you get | What it needs from you |
|---|---|---|---|
| PHP / Laravel | composer.json | nginx + php-fpm, with Laravel routing and 404 handling already wired | Set APP_KEY. If your entry point is not /public, set NIXPACKS_PHP_ROOT_DIR. |
| Node | package.json with a start script | npm run start | You get Node 18 unless you pin it — set engines.node in package.json. |
| Go | go.mod | A compiled binary | Nothing. |
| Python / Django | requirements.txt | python manage.py migrate then gunicorn | WSGI_APPLICATION must be set in your settings. Without it the build stops with that exact message. |
| Ruby / Rails | Gemfile | The Ruby toolchain | A .ruby-version file is required. Without it the build stops immediately. Set a start command if the build does not infer one. |
Honest note. This table is what we tested, not everything that works — the builder supports more languages than these, and a Dockerfile always works. We list what we have run ourselves rather than what we could claim.
URLs
Previews land on a test subdomain, production on your project slug (or a custom domain).
preview {branch}-{hash}.test.{slug}.primdb.dev
production {slug}.primdb.dev (or your custom domain)Two toggles per project
| Toggle | ON | OFF |
|---|---|---|
auto-deploy | A git push triggers a build automatically | You trigger the deploy manually from the dashboard or CLI |
auto-promote | A successful build goes straight to production | The build stays on the preview URL until a human approves it |
The default is auto-deploy ON and auto-promote OFF: pushes build automatically, but production always waits for approval.
Approval-gated promotion
- Every build lands on a test subdomain first.
- An Owner or Developer reviews it and approves before it reaches production.
- The first-ever deployment for a project auto-promotes, because there is no previous production to protect.
Operations
- Rollback — one click (or
primdb rollback) back to any previous production deployment. - Force-promote — Owner-only bypass for hotfixes; skips the test subdomain and is flagged in the audit log. From the CLI:
primdb deploy --force-prod. - Reject — a reviewer rejects a build with a reason; the test subdomain stays live for 24h for debugging, then is cleaned up.
Deployment lifecycle
| State | Meaning |
|---|---|
pending_review | Build succeeded, awaiting approval |
production | Approved and live at the production URL |
rejected | Rejected by a reviewer |
superseded | Replaced by a newer build on the same branch |
expired | Pending review for more than 7 days without action; cleaned up automatically |
rolled_back | Was production, now replaced by a rollback |
CLI commands
primdb deploy # deploy the current branch at HEAD
primdb deploy --branch feature/x # deploy a specific branch
primdb deploy --wait # block until the build completes, stream logs
primdb deploy --force-prod # Owner only: bypass the approval gate
primdb deployments # list deployments (ID | STATUS | PROMOTION | ...)
primdb promote <id> # approve a preview to production
primdb rollback # roll back to the previous production deployment
primdb rollback --to <id> # roll back to a specific deploymentHonest note. The build system runs on Nixpacks with rootless Docker on Hetzner worker nodes, behind a single Caddy-fronted relay. The target for a git push to a live preview is under two minutes.