Dockerfile. By the end, a push or pull request gives you a live URL.
The dashboard: live deployments, recent activity, and build times at a glance.
New here? Your dashboard shows a Getting started checklist that walks you through these same steps — connect a repo, deploy it, open your live app — and ticks each one off as you go.
1. Sign in
Sign in with GitHub or GitLab. Slipway uses your code host for identity — there are no passwords. First time in, you’ll be prompted to connect an account.2. Connect GitHub or GitLab
GitHub: click Install Slipway GitHub App and choose which account and repositories to grant. You can scope it to a single repo while you try things out; repos you don’t grant stay invisible to slipway. GitLab: click Continue with GitLab and pick a group (you need Maintainer or higher) or your personal namespace. Slipway wires up webhooks and ingests the projects — see Connecting GitHub & GitLab for details. When you come back, slipway creates an org named after the account and lists its repos under Repos.One org per upstream account. Re-connecting the same GitHub account or GitLab group signs you back into the same org. A different account creates a different org.
3. Pick a plan
Slipway routes you to the plan picker, and you have to choose one — no plan is picked for you. Until you do, the org is read-only: you can browse, but deploys are blocked. Every plan gets 30 free days. Starter asks for no credit card at all: start, deploy, and add one only if you stay. If those 30 days end with no card on file, your environments pause until you add one, and nothing is ever charged silently. Team and Business take a card up front and simply don’t charge it for 30 days. See Plans & pricing.4. Add slipway.yaml
Create a file called slipway.yaml at the root of your repo. The smallest valid spec:
slipway.yaml
Dockerfile at the repo root, exposes port 3000 publicly, and waits for /healthz to return 2xx before going live. Adjust the port and path for your app — the Services reference covers every field.
5. Deploy the repo
As soon as your plan is picked you land on Deploy a repo (it’s also one click away from the dashboard, the Repos page, and the Environments page). Pick your repository, keep the default branch, and hit Deploy — or skip to the dashboard and come back later. That one button creates an environment for the repo, starts the first build, and drops you on the live deployment page. Slipway validates your spec along the way; ifslipway.yaml is missing or malformed, it tells you exactly what’s wrong before anything runs.
The phase ladder on the deployment page tracks build → deploy → live.
A live deployment: phase ladder and public URLs up top, per-service progress below.
Deploying more than one repo together, or a PR-preview-only setup with nothing permanently running? Use the environment composer instead (Environments → New environment) — see Environments.
6. Push and open pull requests
When the status reaches healthy, the deployment page shows the public URL. From here the repo behaves the way you’d expect:- Push to the tracked branch and slipway rebuilds and redeploys it automatically. The environment header shows whether it’s set to auto-update or pinned.
- Open a pull request (or merge request on GitLab) and slipway builds a separate preview with its own URL, torn down when it closes. If PR comments are on (the default), the URL is posted into the thread.
Next steps
Secrets & variables
Wire
DATABASE_URL, API_KEY, and friends in without committing them.Custom domains
Serve previews under your own domain instead of the default.
Repository settings
Auto-deploy, PR comments, and preview authentication.
Deployments
Triggers, manual deploys, and the deployment lifecycle.