ready. Then it’s live on a unkey.app domain.
That’s the default, with auto deploy on and no watch paths. If you turn auto deploy off or set watch paths, a push can be recorded as skipped instead of built. A pull request from a fork waits in awaiting_approval until a member approves it.
An deploys and serves traffic. By the end of this guide you have a project, an app connected to the repository, and a production deployment.
If you’d rather bring an image you built yourself, see Deploy a container image.
You need a Compute plan before you can deploy. If you don’t have one yet, the dashboard asks you to pick one the first time you try (the dialog is titled Choose a Compute plan). Only a workspace admin can do that. See Compute plans for what each plan includes.
Create a project
Open Projects in the dashboard and choose Create project. The dialog asks for a Project Name and a Slug. The slug is generated from the name, and you can edit it. The slug is the identifier you’ll pass to the API and the CLI, it must be unique in your workspace, and 
default is reserved.Pick the repository
On Deploy a new app, pick GitHub repository. To add an app to a project later, open the project and choose Create app.
-2, -3, and so on.Check the settings
The branch starts as the repository’s default branch. The defaults build and run most repositories without changes:
- Build: with no Dockerfile set, Unkey detects your language and toolchain and builds the image. See Build settings.
- Scaling: each app starts with 0.25 vCPU, 256 MiB of memory, and one instance in each region available to the workspace. See Runtime settings.
- Environment variables: mark secrets as sensitive to make them write-only. See Environment variables.
PORT environment variable. The port is set per environment and is 8080 in each one. To change it for one environment, open App settings > Environments, select the environment, and click Configure on the Runtime card.Going back keeps your saved settings. Picking a different repository connects it to the same app.Leaving before you deploy asks you to discard the app. An app that was never deployed reopens this flow.Deploy
Choose Deploy. The dashboard creates a deployment in the production environment from the head of the selected branch and opens the deployment page. The deployment moves through 
pending, starting, building, deploying, network (shown as Assigning Domains), and finalizing before it reaches ready. The build log streams while building runs. A first build waits its turn if another deployment in the workspace is running.When the status is ready the app is live on its automatic domains. With a project payments, an app api, and a workspace acme, the production deployment answers on payments-api-acme.unkey.app, with further domains for the environment, the branch, and the exact commit. If the app slug is default the domains omit it and start with payments-. The deployment detail page lists every domain.failed, the detail page shows the step that failed and an error code. Deployments lists the codes and what to change.Push again
From now on GitHub tells Unkey about every push. A push to the app’s default branch creates a production deployment, and when it reaches
ready it becomes the live deployment and the production domains move to it. A push to any other branch creates a preview deployment with its own branch domain, so every branch has a URL you can share. A pull request from a fork is held in awaiting_approval until a project member approves it, because it runs code from outside your repository.Auto deploy and watch paths decide whether a push builds at all. A push that isn’t built is recorded as skipped with the reason.