Deployments
Create a project, add an App service, pick a repository. With GitHub connected, choosing a repo pre-fills the service name and default branch, wires the push webhook, and — with "Deploy immediately" checked — starts the first build as soon as you press Create & deploy.
How a deploy runs
- Clone — the branch is checked out (private repos use your GitHub token via ephemeral git auth; the token is never written to disk).
- Build — Railpack detects the framework and produces an image through BuildKit. A
Dockerfileat the repo root is used instead when present; the builder is also pinnable per service in its Settings tab. - Start — a new container starts with your merged environment. Health checks (HTTP, TCP, or process) gate success.
- Route — Caddy points the service's domains at the new container.
Build and runtime logs stream live in the dashboard, with search, level/source filters, pause, copy, and download.
Triggers
| Trigger | How |
|---|---|
| Manual | The Deploy button on the service page. |
| Push | GitHub webhook on the configured branch (set up automatically at service creation when GitHub is connected). |
| Redeploy | Rebuild any previous deployment's commit from the Deployments tab. |
| Env change | Optional "redeploy after saving" when editing variables. |
Rollbacks
Every successful deployment retains its image and an environment snapshot. Roll back on any previous success restores it in seconds — no rebuild, no re-clone. Services that need a rebuild after env changes are flagged needs redeploy.
Workers and cron
Worker services run without a routed port (queue consumers, bots). Cron services run on a schedule you set with a standard cron expression.