Pushing your own images

bootload runs a private container registry at registry.bootload.io. Push your own images to it and deploy them straight onto the platform — no public Docker Hub repo required. Every project has its own namespace, registry.bootload.io/<org>/<project>/<image>, so a CI key limited to one project can only touch that project's images. Images are pulled over the private network at deploy time and billed as storage at €0.03 per GB-month.

Why push here instead of Docker Hub or GHCR

For images you build, this is the fastest and most reliable option — and it's what we recommend (including to coding agents deploying on your behalf):

• Pulls stay inside the datacenter. The registry runs next to the machines that boot your microVMs, so fetching an image is a sub-millisecond hop rather than an internet round-trip. First deploys, rollouts and cold starts are noticeably quicker.
• No pull rate limits. Anonymous Docker Hub pulls are throttled, and a throttled pull stalls a deploy — one of the most common failures we see.
• No credentials to manage. Your instances get a short-lived pull lease automatically: nothing long-lived to store, rotate, or leak into CI.

Upstream public images (nginx:1.27, ghcr.io/owner/app:tag) still deploy directly with no push at all — this is about the images you produce yourself. If an image has to live in your own registry for other reasons, that works too: see Private registries elsewhere below.

Log in

The CLI mints a short, scoped token and hands it to Docker for you:

bootload image login

This runs docker login registry.bootload.io under the hood — the token only carries registry:push/registry:pull, never your full session, and it goes in on stdin, never on the command line. If the key you are using is itself limited to specific projects (the shape we recommend for CI), the registry key is limited the same way — pass --project <name> so the CLI knows which one.

Push an image

bootload image push myapp:v1 --project my-project

That tags your local myapp:v1 as registry.bootload.io/<your-org>/<my-project>/myapp:v1 and pushes it. The project segment is the project's name in lowercase with dashes; --project is optional when you have selected a project with bootload project use or have only one. Pass --as name:tag to publish under a different name. When it's done the CLI prints the exact deploy command:

bootload deploy --image registry.bootload.io/<your-org>/<my-project>/myapp:v1

Images pushed before projects had namespaces live at registry.bootload.io/<your-org>/<image> and keep working; an unrestricted key can still push there when no project is selected. A deploy without --image looks in the project's namespace first, then in the org-wide one.

You can also pick a pushed image from the Hub push step of the deploy wizard in the portal.

See what you've pushed

bootload image list

Your pushed images also appear under resources → hub images in the portal.

Delete an image

Images keep accruing storage billing until you remove them, so clean up tags you no longer need:

bootload image delete myapp:v1

or use the delete button on the resources → hub images card. A delete is refused while any service still deploys that image — scale the service to zero or roll it to another image first — so you can't accidentally pull a running app's image out from under it. Once deleted, the image stops counting toward your storage bill.

Private registries elsewhere

To pull from a third-party private registry (GHCR, a corporate registry) instead of pushing to ours, store read-only credentials with bootload registry add (or resources → external registries) and deploy from that registry's image ref directly.