Skip to main content
If your repository already has a Compose file, slipway can deploy it directly. It reads and converts the file on every deploy, the same way it reads a slipway.yaml. Nothing is written back to your repository, and conversion needs no extra permissions. slipway stays read-only on your code. A committed slipway.yaml takes precedence unless you pin a Compose file.

​
Getting a Compose repo deploying

  1. Create a project for the repo. Select New in the sidebar and choose your provider.
  2. Pick the Compose file, if the repo has more than one. slipway remembers the choice.
  3. Fill in the values the file references. The secrets manager on the service’s Spec view shows which ${NAME} references are still missing.
  4. Deploy. Every push reconverts the current file and deploys it.
Recognised filenames are docker-compose.yml, docker-compose.yaml, compose.yml and compose.yaml, plus docker-compose.*.yml and compose.*.yml overlays.

​
What translates

Compose’s build block is flattened onto the service: the context becomes rootDir and the rest sit beside it. A named volume mounted by exactly one service becomes that service’s disk. Compose declares no size, so slipway provisions 10 GB and records that in the conversion notes. Adjust disk.sizeGB in the generated spec if the workload needs more, because the size is fixed once the disk is created. A named volume mounted by several services has no equivalent, since slipway gives each service its own disk rather than sharing one. Those mounts are dropped with a warning: the paths stay writable but the data is ephemeral. Point both services at a database instead. A bind mount of a committed repository file, the classic ./init.sql:/docker-entrypoint-initdb.d/init.sql, is projected into the container read-only, so init scripts and config files work unchanged. See files.

​
What is dropped

Database and cache services run as stateless containers unless a named volume gave them a disk. For data that has to survive, declare a managed database in a slipway.yaml, or point your app at an external provider through a secret.

​
Interpolation

Write Compose interpolations exactly as you do locally. The same ${VAR} resolves on slipway, secret store first and then variable store, each scoped project then organization. Shell modifiers work too: slipway lists every referenced key and seeds each as a variable or a secret by name. Change a row’s type if the guess is wrong.

​
x-slipway overrides

For the few things Compose cannot express, add an x-slipway block to a service. docker compose ignores it.
docker-compose.yml
Most repositories need none of this. The defaults infer the public port, and depends_on, volumes and interpolation all work without annotation.

​
Moving to slipway.yaml

Compose is a good way to get deploying without changing the repo. Once you want disks sized properly, managed databases, previews or scaling, export the converted spec from the service’s Spec view and commit it as slipway.yaml. From then on the file is authoritative.