Deploy an image

Web services and workers can run from an image. Image services need a plan.

Create an image service

1. In a project, create a web service or a worker and choose an image as its source.
2. Enter the image reference, for example ghcr.io/myorg/api:2.4.
3. Set the port the image listens on, if it isn't 8080.
4. Set its CPU and memory, and a volume if it keeps files (Volumes).
5. Optionally, set a start command.
6. For a web service, choose its address label, which defaults to the service name.

The service deploys as soon as you create it. If it needs variables, choose to add them first: wabi creates the service without starting it, and you deploy once the variables are signed.

To deploy, wabi resolves the reference to a digest, pulls the image, and starts it in its own microVM. The deployment goes live once the service passes its health check (Health checks).

Image references

wabi reads a reference the way Docker does. The first part of the path names a registry only when it contains a . or a :, or is localhost. Otherwise the image is on Docker Hub.

wabi pulls the image without credentials, so the image must be public.

References wabi refuses

wabi pulls only from registries on the public internet. It refuses a reference whose registry is:

• an IP address, such as 203.0.113.10/app,
• localhost,
• a host without a dot, such as myregistry:5000/app,
• a name ending in .internal, .local, .localhost, .svc or .cluster.local,
• a host that resolves to a private, loopback or link-local address.

wabi checks the reference when you save it and again each time it contacts the registry.

Start command

Without a start command, the image's own entrypoint and command run. A start command replaces both:

node dist/server.js

wabi runs it with /bin/sh -c when the image has a shell, so &&, pipes and variable expansion work. In an image without a shell, wabi splits the command into words and runs it directly. The working directory and the user stay the image's own.

An image with neither an entrypoint nor a command needs a start command. Without one, the deployment fails with image has no entrypoint or command.

Port

wabi sends traffic to the service's port and sets PORT to it. The port is 8080 unless you set another.

An app that listens on PORT needs nothing more. An image that listens on a fixed port needs the port set to match: nginx listens on 80, so set the port to 80.

Redeploy

Redeploying pulls the image again. A tag that has moved since the last pull, such as latest, now resolves to a new digest, and that is what runs.

Each deployment records the digest it ran. Rolling back to it runs exactly those bytes, whatever the tag points to by then.

Change settings

While a deployment is live, changing the image, port, CPU, memory, start command, pre-deploy command or health path starts a new deployment with that change. It goes live once its health check passes, and if it fails, the live deployment keeps serving.

The pre-deploy command runs on the new image before the rollout, as described in Deploy from GitHub.

Rollback

You can roll back to an earlier deployment from the service's deployment list. A rollback starts a new deployment with that deployment's image and settings and your current variables, with nothing to rebuild (Rollback).