Documentation

Sources

Every service comes from one of two places: a Git repository we build, or a container image we pull. There is no third option.

From a Git repository

Point a service at a repository and a branch. Each deploy builds that branch and records the commit it came from, so the deploy history reads as a list of changes rather than a list of timestamps.

Connect GitHub in Integrations to list your repositories and read their commits. A public repository deploys with no GitHub App installation at all — worth knowing, because such an app has a full working deploy history and still cannot list commits, which is a normal state and not an outage. The five reasons a commit list is absent are on Versions.

What gets detected

When you pick a repository we read it and try to work out how it builds, filling in four things you would otherwise type: the install command, the build command, the start command, and the port the service listens on. Detection covers Node, Python, PHP, Ruby, Go, Java, Rust, .NET, Elixir, Deno and plain static sites.

Everything it fills in is an ordinary editable value, not a locked suggestion. If it guessed a port wrong, change it.

Detection failing is not your problem to fix, and it never blocks a deploy. If the repository cannot be read — no integration, no access to that repo, a rate limit, or an error our end — the form simply shows nothing detected. It does not raise a warning and it does not stop you, because a convenience that failed is not a fault in your code. Fill in the commands yourself and deploy.

From a container image

A service can instead name an image to pull, which is the right choice for software you did not write: an off-the-shelf tool, or a build produced by a pipeline somewhere else. Give the image reference and the port it listens on.

For a private registry, add the credentials in Integrations — Docker Hub and GitHub Container Registry are both supported. Without them a private image cannot be pulled, and the deploy will say so.

A Git service is built, so it has commits, a branch, and a Dockerfile path.
An image service is pulled, so it has none of those — only a reference and a port.

An image-sourced service has no commits, ever. It still gets a full deploy history you can put a previous image back from — see Versions.

One or the other, per app

An app runs one service, so it is sourced one way or the other: your repository, which we build, or an image, which we pull. The choice is made when the app is created and can be changed later — it is not a property you are locked into.

Running your own repository alongside a stock image in one app — a front end you build next to a tool you did not, sharing a URL and going back together — needs several services per app, which is on the roadmap.