Skip to main content
You need a GitHub or GitLab repository. A Dockerfile helps but is not required: a repo without one can build on a language runtime. At the end of this page a push to your tracked branch deploys automatically.

​
1. Sign in

Sign in with GitHub or GitLab. slipway uses your code host for identity, so there is no password to set.

​
2. Connect a provider

Select Install slipway GitHub App, then choose the account and the repositories to grant. You can scope the install to a single repository while you try things out. Repositories you do not grant stay invisible to slipway.
slipway creates an organization named after the account and lands you on its project list. See Connecting GitHub and GitLab for permission detail.
Re-connecting the same GitHub account or GitLab group signs you back into the same organization. A different account creates a second organization.
Your organization starts on the Free plan with a one-time $5 usage grant and no card. That is enough to build, deploy and run a small service long enough to evaluate it. When the balance reaches zero, projects pause rather than being deleted. See Billing.

​
3. Add a slipway.yaml

Create slipway.yaml at the root of your repository. The smallest spec that deploys:
slipway.yaml
This builds the Dockerfile at the repository root, serves port 3000 publicly, and waits for /healthz to return a 2xx before cutting traffic over. Change the port and the path to match your app. Services covers every field.
If your repository already has a docker-compose.yml, slipway can deploy from that instead. See Docker Compose.

​
4. Deploy

Select New in the sidebar, choose GitHub Repository or GitLab Project, pick your repository, keep the default branch, and select Deploy. This creates a project for the repository, starts the first build, and opens the service’s Logs tab. If slipway.yaml is missing or invalid, slipway reports the problem and the line it is on before anything is built. The phase ladder in the service header tracks building → deploying → healthy while the log streams below it.

​
5. Push to deploy

When the status reaches healthy, the service header shows the public URL. From here, a push to the tracked branch rebuilds the service and cuts the same URL over to the new build once it passes its health check. The project header shows whether the project auto-updates on push or is pinned to a commit.

​
Next steps

Secrets and variables

Set DATABASE_URL and friends without committing them.

Add a database

Managed Postgres, Redis, MySQL or ClickHouse alongside your service.

Custom domains

Serve your services under your own zone.

How deploys work

Triggers, build caching, cutover and teardown.