Skip to main content

Deploy

Deploying is the act of putting a new version of the application live. The platform fetches the code, builds the image, and activates the new version — the previous one keeps serving until the new one answers.

Before you start​

  • The project needs a source: the repository every one of its services deploys from. It is set when creating the project and can be changed under Source.
  • The Dockerfile must exist in the deployed folder. See How the image is built.
  • The application must listen on 0.0.0.0, on the port from the PORT variable. See How the application runs.

Step by step​

  1. Open the project and click Deploy.
  2. Check what the confirmation shows:
FieldWhat it is
ServiceWhich service will be deployed, when the project has more than one
SourceThe declared repository and folder
Branch or tagEditable — whatever is in the field is what gets deployed
EnvironmentThe deployment target
ResourcesCPU and memory reserved and maximum, with a warning when they are the platform default
AddressThe address that will answer
  1. Click Deploy now.

The console takes you to Deployments, where the deployment shows up right away, in the Deployment in progress section — with no need to reload the page. See Following a deployment.

Deploying another branch is a legitimate use

The branch field is editable in the confirmation. Deploying a branch other than the declared one does not change the project's configuration: it applies to that deployment.

What happens after you confirm​

Preparing → Building → Deploying → Verifying → Online

The immediate response is not the result — it is the progress. See Following a deployment.

Repeated deployments​

A double click, or a reconnection in the middle of the request, does not create two deployments. The operation is protected against repetition.

What creates a new version​

Not just new code. Every change affecting how the application runs creates a new version:

Changing variables or resources does not change the application already running: the configuration screens warn that the change takes effect on the next deployment, and the resource screens can redeploy the service with the same image.

Cancelling​

A deployment in Preparing or Building can be cancelled. Once the artifact has been pushed, cancelling stops being an option — the option becomes restoring the previous version.

Cancelling before the traffic switch produces no visible change: the version that was live stays live.

When it fails​

A failed deployment does not leave the service without an active version. The previous one keeps serving, intact.

Open the failed deployment: the timeline shows which step it stopped at, and the build log shows the builder's output.

When the build passes and the application does not become ready — it never started, stopped right after starting, or started and did not answer on the port —, the deployment fails with that reason and the action, switching nothing. See Deployment states. Common cases in Common problems.

Next steps​