> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy from an image

> Run a prebuilt container image with no repository behind it.

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

**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.

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.

**slipway.yaml**

Set `image:` on the service instead of the build fields.

```yaml slipway.yaml theme={"system"}
version: 1

services:
  - name: api
    image: ghcr.io/acme/api:1.2
    ports:
      - port: 8080
        public: true
    env:
      LOG_LEVEL: info
```

`image:` and the build fields (`rootDir`, `dockerfilePath`, `dockerTarget`,
`buildArgs`, `runtime`, `runtimeVersion`, `buildCommand`) are mutually exclusive. A
service declares one source or the other.

`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](/organization/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.

> [!NOTE]
>
> 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](/slipway-yaml/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:`](/slipway-yaml/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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.