Speed and cost

Make servers ready faster

Where boot time goes, what a prebaked image changes, how to check readiness, and what is coming next.

Reviewed 2026-10-02

A server is useful when your services answer, not when the provider says it exists. This page shows where the time goes between chalupa up and a ready stack, what you can change today, and what is not built yet.

Where the time goes

The server boots. The provider creates the machine. This is the part you cannot shorten.
The host is prepared. On a stock image, cloud-init installs Docker and the tools Chalupa needs, then writes your per-environment files.
Images are pulled. Every service image is pulled from its registry on the new server, every time.
Your own app images arrive. Chalupa refuses build in Compose, so an app image you build yourself has to be built and shipped to the server. chalupa apps build and chalupa apps up print the script for that; they do not run it.
Data is seeded. Importing a large dataset can take longer than all of the above.
Your services start. A database that recovers a large index, such as Elasticsearch restoring its shards, can take minutes on its own.

One measured stack

These are the only measured figures Chalupa has, from one anonymised stack on one provider in August 2026, on an image that already had Docker installed:

The server and its Docker setup were ready in 4 to 5 minutes.
Stacks that also built and shipped their own app images took 10 to 40 minutes to be ready.

A first-time user boots a stock image, which installs Docker first, so expect more. Your stack, region and registry will change every number. Per-run timing receipts are coming next, so time to ready is measured for each run and not estimated.

Prebaked images

Status: Beta. A prebaked image already ships Docker, the tools, static scripts, system users and pre-enabled systemd units. cloud-init then skips package installation and writes only your per-environment payload.

compute:
  image: "123456789"   # the id of your golden snapshot
  prebaked: true

prebaked: true requires image to be a golden snapshot. The image masks background apt jobs, so boxes booted from it never run apt on their own, and picking up operating system updates means baking a new one. It also records what it contains in /etc/chalupa/golden.json: the Chalupa version, the bake time, the provider and the Monitor version.

Build the image with chalupa snapshot build --config PATH --confirm "bake <name>": it prints the estimated cost and time first, creates a temporary billable server, and changes nothing without --confirm. Set compute.image: golden:latest to follow the newest golden this machine baked, and chalupa snapshot status lists them with their age. The agent, forwarder and Monitor are refreshed over SSH on every chalupa up, so the image does not freeze them, and chalupa doctor --config warns when the golden in use is stale. See compute.

Readiness probes

compute.readiness declares typed probes that must all pass before a stack counts as up: tcp, http, mongo, amqp and a cmd escape hatch. They replace hand-written wait scripts.

compute:
  readiness:
    - tcp: { service: postgres }
    - http: { service: web, path: /healthz }
    - cmd: { command: "node scripts/wait-es.mjs", timeoutSeconds: 30 }

Probes run on your machine against the tunnel, so the tunnel has to be open. chalupa wait runs them through it and prints when each became ready; chalupa up --wait opens a supervised tunnel and waits for them before it returns, and the same probes gate the specs of chalupa test and the command of chalupa exec. See compute.readiness. compute.health is a separate, single check: chalupa up and chalupa test both wait for it through a temporary tunnel and fail if it never answers. chalupa preview shows the declared probes offline.

Do not rebuild a server mid-run

Rebuilding a server throws away everything above. If a run needs more time:

chalupa session extend --hours 2 lengthens the session while the server is still running. It is billable, so it asks for a typed confirmation.
chalupa session renew re-leases an expired session whose server is still running, within session.maxLifetimeHours.

Seed once

A large import should not run on every launch. Declare persist and run chalupa data-up once, then chalupa seed. The data volume lives in its own stack and survives teardown, so the next chalupa up starts from the seeded data. It bills monthly until you delete it on purpose. See data and seeds.

Status

Piece	Status	What it does
Prebaked server image	Beta	`compute.prebaked: true` boots from an image that already has Docker and the tools. You build it with `chalupa snapshot build`.
Warm server	Coming next	Keep a server alive between runs. It will be opt-in: declared in your config and shown when you confirm.
App swap	Coming next	Swap your app's code on a running server without rebuilding the whole image.
Cache volume	Coming next	A separate, disposable cache volume so repeat boots skip image pulls. It never shares your protected data volume.
Run receipts	Coming next	A timing and cost receipt for each session, so time to ready and spend are measured instead of estimated.

None of the Coming next rows work yet. Until they ship, the faster path is a prebaked image, a seeded data volume and a longer session instead of a rebuild.