# Deploy

> Git-connected deployments with per-branch previews, an approval gate before production, and one-click rollback.

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.

## URLs

Previews land on a test subdomain, production on your project slug (or a custom domain).

```text
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

```bash
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 deployment
```

> **Honest 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.

---

Source: https://primdb.com/docs/deploy