Getting started

bootload deploys OCI container images into dedicated Firecracker microVMs. If your app runs in Docker, it runs on bootload.

The mental model

• An organization owns projects and people.
• A project has a private network, a wallet, and your apps.
• A service is one deployed image; it can have replicas, volumes, secrets, and domains.
• Everything is prepaid per second from the project wallet.

Your first deploy

Follow the quickstart — five commands. The short version:

bootload signup --email you@example.com
bootload org create "My Company"
bootload project create production
bootload wallet topup --amount 10
bootload deploy --image ghcr.io/you/app:latest --port 3000:http

Images and registries

Public images deploy directly. Private registries work via stored pull credentials (bootload registry add) — tokens are encrypted, write-only, and never reach your VM. Or push straight to the bootload hub with docker login and deploy with no --image at all.

Secrets

bootload secret set DATABASE_URL          # project-wide
bootload secret set API_KEY --service api # one service only

Secrets are injected as env vars and /run/secrets/* files at boot — they never touch the image, the disk, or the logs. Service-scoped values shadow project-scoped ones with the same name.

When something fails

bootload status shows the failure reason per replica (including registry rate limits, with the fix suggested). bootload logs <svc> -f follows your app's stdout. Deployments that can't get healthy are marked failed with the cause — never silently retried forever.