Skip to main content
Unkey Deploy is in public beta. To try it, open the product switcher in the top-left of the dashboard and select Deploy. During beta, deployed resources are free. We’re eager for feedback, so let us know what you think on Discord, X, or email support@unkey.com.
Unkey gives you two first-class ways to ship code: connect a GitHub repository and let Unkey build and deploy on every push, or build the image yourself and push it with unkey deploy. Both produce the same deployment artifact — an immutable version running in an environment with a commit-scoped domain. The difference is who owns the build. This page helps you pick the right path.

TL;DR

Use GitHub integration

You want zero-config, push-to-deploy. You’re happy letting Unkey handle image builds on every commit. This is the right default for 95% of apps.

Use the CLI

You already have a CI/CD pipeline, you need control over the build (monorepo, custom build matrix, pre-release artifacts), or you don’t want to connect a GitHub repository.

Side-by-side

CapabilityGitHub integrationCLI (unkey deploy)
Who builds the imageUnkey, using your Dockerfile on every pushYou (locally, in CI, or wherever) — Unkey pulls a tag
Triggergit push (webhook)You run a command
Repository requiredYes, connected to the Unkey GitHub AppNo
Preview per branchAutomatic on every non-default branchYou call --env=preview (or any environment) explicitly
Build logsStreamed to the dashboard in real timeWherever you run the build (your CI logs, your terminal)
Build concurrency quotaCounts against workspace max_concurrent_buildsDoes not count — the build happens outside Unkey
Watch paths (skip irrelevant changes)Supported — configure in app settingsNot applicable — you decide when to call the CLI
Fork protectionBuilt-in: PRs from forks require approvalNot applicable
Superseded cancellationQueued builds auto-cancel when a newer commit landsNot applicable — you control cadence
Works without GitHubNoYes (any Git provider, or no Git at all)
Reproducible local deploysIndirect (push, then wait)Direct (run the same command you’d run in CI)
Ideal forProduct apps, preview URLs per PR, fast iterationCI-driven release pipelines, monorepos, custom build graphs

When to pick the GitHub integration

Connect a repository when you want push-to-deploy with no additional infrastructure:
  • Product-style apps where every PR should get its own preview URL automatically.
  • Small teams that don’t want to run or maintain a separate CI pipeline for builds.
  • Fast iteration during early development — you push, Unkey deploys, done.
  • You need fork protection for open-source repositories.
  • You want watch paths to skip builds for doc-only changes.
Setup is three clicks in the dashboard: install the GitHub App, select a repository, click Deploy. See GitHub integration for the full walkthrough.

When to pick the CLI

Reach for unkey deploy when you need control over the build step, or when connecting a repository isn’t an option:

You already have a CI/CD pipeline

If you’re building images in GitHub Actions, GitLab CI, CircleCI, Buildkite, or anything else, you’ve likely invested in:
  • Custom build steps — code generation, compilation, asset bundling, SBOM generation, vulnerability scans.
  • Build caching — layer caches, dependency caches, test fixtures.
  • Test gates — unit, integration, and end-to-end tests that must pass before shipping.
  • Artifact signing — Cosign, Sigstore, or organization-internal signing.
Rebuilding the same image on Unkey’s side is wasted time and compute. The CLI lets your existing pipeline produce the image once and then deploy it:
# In your CI, after the image is built and pushed:
unkey deploy $REGISTRY/$IMAGE:$SHA --project=api --env=production

You want deploys decoupled from Git pushes

Some teams don’t want every main push to ship to production:
  • Release trains where pushes go to a staging environment and a separate job promotes to production.
  • Manual release gates that require approval outside GitHub.
  • Scheduled deploys triggered by cron, not by commits.
With the CLI, pushes to main don’t automatically deploy. Deploys happen when something (a workflow, a human, a scheduler) explicitly runs unkey deploy.

You don’t use GitHub

The CLI only needs a Docker image in a registry. That works with GitLab, Bitbucket, self-hosted Git, or no Git at all.

You want reproducible local deploys

Running unkey deploy from your laptop ships the exact same artifact you’d ship in CI. Useful for debugging a deployment issue end-to-end without burning CI minutes.

Next steps

Deploy with the CLI

Step-by-step guide for unkey deploy, including a GitHub Actions example

GitHub integration

Set up push-to-deploy from a connected repository
Last modified on April 27, 2026