Tinycloud boots each deployment from an immutable guest image. Building one is an operator task, not something that happens during a deployment.
tools/setup-cloud.sh builds both images for you. This page is for manual and hosted installations, and for producing a new image release.

​
The serving image

From a prepared minimal Linux root directory:
The builder:
1

Validates the guest prerequisites

Node.js 22, wget, iptables, setpriv, a POSIX shell.
2

Requires a UID/GID 1000 account

Tenant code never runs as root.
3

Installs the repository's init

/sbin/tinycloud-init from packages/provider-firecracker/guest.
4

Refuses to overwrite an existing image

Deliberately — replacing a live image out from under running VMs is not a thing you want to do by accident.

​
What the init does

The init mounts the data drive, reads MMDS into the worker’s stdin, blocks all subsequent MMDS access, drops permanently to UID/GID 1000, and starts Node with filesystem permissions that let tenant code read its artifact and write only the state directory.
The guest receives only the platform’s Ed25519 public verification key, never its signing key. A compromised VM cannot mint a token.

​
The build image

Only needed if you want to offer build.command. Produce it from a root directory that also contains npm, tar, and git:
Without TINY_FIRECRACKER_BUILD_ROOTFS the platform reports executesBuildCommands: false. It never falls back to building on the host.
The serving image deliberately lacks this toolchain. That is the point: a serving VM has no compiler, no package manager, and no git.

​
The kernel

Firecracker needs a compatible vmlinux. tools/setup-cloud.sh downloads a checksummed Firecracker release and the official guest kernel.

​
Image releases

Kernel and base-rootfs patching are an operator image-release process. They are not performed during an app deployment, and an app cannot influence them.
A sensible release loop:
1

Build the new image beside the old one

The builder refuses to overwrite, which enforces this.
2

Point TINY_FIRECRACKER_ROOTFS at it and restart

Running VMs keep their existing image.
3

Redeploy apps to move them onto it

Each redeploy boots a candidate from the new image and health-checks it before switching traffic — so a bad image fails one app’s rollout rather than taking the fleet down.
4

Keep the previous image until every app has moved

A rollback needs it.

​
Verify

executesBuildCommands in that response tells you whether the build image was found.