Skip to main content
A service can run an image you built elsewhere. There is no build phase, so a deploy is a pull and a rollout.

From the console

Select New, then Docker Image. Enter a pullable reference such as ghcr.io/acme/api:1.2, the port the container listens on, and its CPU and memory.

From a spec

slipway.yaml
image: and the build fields are mutually exclusive. A service declares one source or the other. The image must be linux/amd64, or a multi-arch manifest that includes it.

Private registries

Add the credentials once under Settings → Registries. slipway attaches them to every pull in the organization that needs them, and there is nothing to reference from the spec. See Private registries.

Tags are pinned

slipway resolves the reference at deploy time and pins what it resolved. Pushing a new image to the same tag does not redeploy anything, including :latest. To pick up a new image at the same tag, redeploy the service. To move to a different image, change the reference and deploy. Because the tag is pinned, a rollback re-runs the exact image the previous deploy used.

Deploying from CI

An image-backed service has no branch to watch, so it does not auto-deploy. Trigger a redeploy from your pipeline after pushing a new image, using the MCP server or the console.

Mixing with built services

A project can hold built services, image services and managed databases together. They share one network and reach each other by name:
slipway.yaml

Next steps

Deploy from an image

Configuration, pinning and what image services cannot do.

Marketplace

Ready-made apps that already have a spec.