Skip to main content
Deploying applications on Unkey is in public beta. To try it, select Projects in the dashboard sidebar and create a project. Deployed resources are free until August 1, 2026. 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

​
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:

​
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 May 6, 2026