Skip to main content
A service can run an image you already built instead of building from source. slipway pulls the image, runs it in the project’s namespace, and treats it like any other service: siblings reach it by name, and a public port gets a URL. An image-backed service has no build phase, so a deploy is a pull and a rollout.

​
Adding one

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.The service’s spec is managed in the console. Edit it from the service’s Spec view, or export it as a slipway.yaml if the service later grows a repository.
image: is not valid on type: static, which has no container.

​
Private images

Private registries are supported. Add the credentials once under Settings → Registries and slipway attaches them to every pull in the organization that needs them. You do not reference the credential from the spec. See Private registries for the per-registry setup, including Docker Hub, GHCR, GitLab, Google Artifact Registry and Amazon ECR.

​
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 at deploy time, rollback re-runs the exact image the previous deploy used, not whatever the tag points at now.

​
Configuration

Environment variables and secrets work the same as for a repository-backed service. Set them at the project or organization level and reference them with ${secret.NAME} and ${var.NAME}. See Secrets and variables. An image-backed service can also use command, args, workDir, files, healthcheck, disk, replicas and scaling, like any other web or worker service.

​
Managed databases are not this

Postgres, Redis, MySQL and ClickHouse have their own creation flow under New → Database. They pin their own image, generate credentials into a project secret, mount a disk at the engine’s data path, and expose a Credentials tab and scheduled backups. Running postgres:18 as a plain image service gets you none of that. Use New → Database, or the databases: block, unless you specifically want an unmanaged container.

​
FAQ

Which platform does the image need to be? linux/amd64. A multi-arch manifest that includes it is fine. Can I deploy an image and a repository in the same project? Yes. A project’s services are independent. Mixing built services, image services and managed databases in one project is the normal case. Does an image service auto-deploy? No. There is no branch to watch. Redeploy it explicitly, or change the reference.