Skip to content
All services

Build and ship · Deploy

Deploy with clarity. Recover with confidence.

Release from GitHub, GitLab or Bitbucket to servers you own, with approvals, safe strategies, previews and a rollback that’s always one click away.

  • Git-connected releases
  • Previews per pull request
  • Blue-green, canary and rolling deploys
  • Rollback in seconds

Deployment #1841

Storefront · production

Health verified

A release record with revision, rollout and verification in one place.

  1. Approve

    Recorded

  2. Release

    Recorded

  3. Verify

    Recorded

Revision
a71c8ef
Strategy
Blue-green
Recovery
Available

Illustrative interface with sample data.

Works with

  • GitHub
  • GitLab
  • Bitbucket
  • DigitalOcean
  • Hetzner Cloud
  • Vultr
  • Deployer API v1

Build and ship

A delivery control plane with the recovery path in view.

From repository to release

Connect a Git provider, get approval, then follow the release through to healthy traffic.

A stack per pull request

Each pull request gets its own website, environment and deploys, removed when it closes.

A visible recovery path

Previous releases stay on the server, so going back to a known revision takes seconds.

Inside Deploy

What you can do

A closer look at what Deploy does, grouped by the work it supports.

Release

Make every deployment traceable

From the first commit to a verified release, every step stays visible and recoverable.

  • Release per buildEach deploy is its own release directory; the previous ones stay for instant rollbacks.
  • Safe strategiesBlue-green, canary and rolling deploys, with health observation and automatic rollback.
  • Secrets from your vaultSync secrets from Doppler, 1Password or AWS Secrets Manager into each environment.
  • Containers and ComposeDeploy a Dockerfile or a whole Docker Compose stack to your own servers, behind HTTPS.
  • Branch environmentsA temporary environment for any branch, with a closing date, as well as for pull requests.
  • PipelinesDeploy several apps in order, such as the API and then the frontend, and stop if one fails.
  • Approvals in SlackApprove or reject a waiting deploy from buttons in Slack or Teams.
  • Release notesNotes written from each deploy’s commits, sent to Slack and published on a public page if you like.
  • Migration safetyDeploys stop before destructive database migrations until someone else approves them.
  • Release analysisEach release is compared with the one before on errors, latency and conversions, and rolled back when it’s worse.
  • Approvals and controlsApproval by someone else, deploy locks with a reason, and weekly deploy windows.
  • PromotionPromote a tested build from preview to development, staging and production, keeping its lineage.
  • Maintenance modeShow visitors a “back soon” page with one click, with a secret link that still lets your team in.

Previews

Review changes before they merge

Every pull request can have a running copy of the application, with secrets kept out of it.

  • A stack per pull requestEach pull request gets its own website, environment and deploys, removed when it closes.
  • Secrets stay safePreviews never inherit secrets; you approve chosen ones for an exact revision.
  • GitHub checksGitHub App repositories get a check run and a comment that follows the preview.
  • Preview databasesStart each preview with a copy of another website’s database, so reviewers see real-looking data.

Automate

Act safely when it matters

Turn repeatable operations into controlled, recorded work.

  • Scheduled deploys and tasksCron schedules in your time zone, task history with output, and alerts when a task starts failing.
  • Workers and hibernationQueue workers and schedulers as services, scaling schedules, and idle environments that sleep until the next request.
  • AutoscalingAdd and remove workers as CPU and queue backlogs rise and fall, within the limits you set.
  • RegionsSee where each environment runs, and run it on websites in more than one region.
  • Clone an environmentStart staging from production’s settings, workers and variables in one step.
  • Environment recipesScripts that run on an environment’s servers, in order, and on new websites if you ask.
  • Configuration as codePlan, review and apply environment configuration documents, from the dashboard or the API.

Integrate

Keep your scripts working

Everything the dashboard does is available to your pipeline.

  • Deployer API v1Deploy, roll back, promote, scale and manage variables from scripts, with scoped API tokens.
  • Signed webhooksPush to deploy from GitHub, GitLab and Bitbucket, with every delivery verified.
  • MonoreposDeploy an app from its folder, and only when a push changes it.
  • Build serversInstall and build on a separate server of yours, then ship the built release through your own bucket.
  • GitHub ActionsAn official action that deploys, waits for the result and comments it on the pull request.

A practical path through Deploy

Connect. Release. Recover.

Keep the path from a source change to production visible to the whole team.

  1. 01Launch with confidenceConnect a repository, pick the servers, and verify the first release.
  2. 02Review before mergingOpen a pull request, share its preview, and promote the tested build.
  3. 03Recover with evidenceSee which release an incident started with, and switch back to the one before it.

Safety and accountability

Keep production actions accountable.

Approvals, locks and windows decide what may ship; the audit log records who shipped it.

  • Encrypted variables and keys
  • Approval by someone else
  • Deploy locks and windows
  • Signed webhooks
  • Retained releases
  • Exact-revision rollback

Good to know

Straight answers about Deploy.

Where does my application run?

On servers in the cloud accounts you connect (DigitalOcean, Hetzner Cloud or Vultr), or servers you import.

Can I go back to an earlier release?

Yes. Retained releases switch back in seconds, and failed live deploys can roll back on their own.

Do my old scripts keep working?

Yes. The Deployer API v1 keeps its paths, fields and status codes, including old numeric IDs.

How are secrets handled?

Environment variables, provider tokens, keys and scripts are encrypted at rest, and previews never inherit them.

Part of BuildPusher

Start with Deploy.

Every service has a free tier. Turn on the others when a project needs them, on the same account and bill.