Deploy
Deploy to your servers. Switch traffic only when it’s healthy.
Unrent deploys a container image, or builds one from your GitHub repository, on your own server. It starts the new release next to the old one, health-checks it, then switches traffic in Caddy, and keeps the previous release for a one-click rollback.
- Clonemain · 8f3c2a12s
- BuildDockerfile41s
- Push imagesha256:6f1e…3s
- Pre-deploy commandnpm run migrate4s
- Start512 MB limit2s
- Health checkGET /healthz 2001s
- Switch trafficCaddy0s
- Drain old releasekept for rollback30s
Sources
Bring an image, or let Unrent build from your repository.
Public images
From Docker Hub, GitHub Container Registry, Amazon ECR Public, Quay and the GitLab registry, pinned by digest on pull.
Private registries
Add a registry user and password; the password is sealed in your browser to your servers and opened only for that pull.
GitHub builds
Install the GitHub App, pick a repository and branch. Pushes deploy on their own, with a check run on the commit.
GitLab, Bitbucket and any Git URL Coming
Other source providers follow GitHub.
Docker Compose and Railpack Coming
Today Unrent builds the Dockerfile in your repository.
Pull request previews Coming
A temporary environment per pull request.
Every deploy, the same safe steps.
- 01
Pull or build
The image lands in the server’s own registry, pinned to its SHA-256 digest. Builds run on the service’s server with a time limit, one at a time.
- 02
Run the pre-deploy command
Migrations run from the new image, with a time limit. If they fail, the old release keeps serving.
- 03
Start and health-check
The new container starts beside the old one. Unrent waits for an HTTP or TCP health check to pass.
- 04
Switch and drain
Caddy moves traffic to the new release, then the old one drains and is kept for rollback.
Roll back without a rebuild
A rollback redeploys an earlier release by its digest, with the config version it ran with. Nothing is rebuilt, so it takes as long as a container start and a health check.
Config changes are versioned too. Changing a variable creates a new version you review and apply, and applying it goes through the same health check and switch.
Environments and promotion.
Production, staging and your own
Every organisation has production and staging; admins add up to 20 more. Each is its own Docker network with its own config and secrets.
Promote the exact image
Promotion deploys the digest that runs in staging to production, with production’s own config. You see the config difference by name before you confirm.
Approval floors
Require one or two passkey approvals before a deploy, config change or rollback reaches an environment.
Several servers per service
Run a service on 1 to 10 servers. Deploys roll out one server at a time and stop at the first failed health check.
Cron jobs
Schedules run your service’s current image with its config and secrets: a five-field cron expression in UTC, a command, a time limit. You see the last run, the next run and its exit code, can run one now, and get an alert when one fails.
The agent runs them on its own scheduler, so they keep running if Unrent is unreachable.
Questions
Does Unrent build my code?
Yes, for GitHub repositories with a Dockerfile. The build runs on the server the service runs on, from exactly the commit that was pushed. Railpack and Docker Compose are coming.
Is a deploy really zero-downtime?
The new release must pass its health check before Caddy switches traffic to it, and the old release drains after the switch. A release that never becomes healthy never receives traffic.
Can my app run on more than one server?
Yes, on 1 to 10 servers per service, with a rolling deploy that halts at the first failure. A service linked to a database stays on that database’s server.
Your servers, your keys. Start with one free server.
The first server is free, then $2 per server per month, with nothing gated.