Skip to main content
slipway deploys GitHub and GitLab repositories to an isolated, internet-reachable project. You describe the services in a slipway.yaml, and slipway builds the images, brings every service up together, gives each public service a clean URL, and redeploys on every push to the tracked branch.

Quickstart

Connect a Git provider, add a slipway.yaml, and get a live URL.

How it works

Organizations, projects, services and deployments, and how they fit together.

slipway.yaml

The manifest format, with worked examples and a full field index.

AI agents

Drive the whole lifecycle from Claude, Cursor or your own agent over MCP.

What you get

  • Push to deploy. Every push to the tracked branch rebuilds the service. The new build takes over the same URL once it is healthy, so links do not change between deploys.
  • Whole stacks. A project can hold a frontend, an API, a worker and a database, drawn from one repo or several. They reach each other by service name on a private network.
  • Always-on services. Services hold their pods around the clock rather than starting on the first request. Rollback re-ships a previous deploy with its images pinned, and does not rebuild.
  • A preview per pull request. Open a PR and slipway can bring up a copy of the project on its own URLs, then tear it down when the PR closes.
  • An MCP server. Agents can create projects, deploy, read logs and exec into a running container to check their own work.

The deploy path

Each project runs in its own network. Services in a project can reach each other, and nothing outside the project can reach in except through a service’s public URL.

Where to go next

Deploy from a repo

The five-minute path from a repo to a live URL.

Deploy a language runtime

Node, Python, Go, Ruby, Rust or Elixir, with no Dockerfile.

Add a database

Managed Postgres, Redis, MySQL or ClickHouse in the same project.

Plans and limits

What each plan allows, and what everything costs.