Fastify-ready Node rootfs forFirecracker
A Fastify-ready Alpine 3.21 + Node.js 22 LTS Firecracker rootfs for long-lived dashboard-IDE endpoints — baking fastify, undici, zod, and pino so staff VMs boot with the server libraries already on disk.
Baked for instant boot
This is the long-lived deploy rootfs for Node endpoints submitted through the dashboard IDE — week-to-month TTL VMs where paying a build-time npm install is the right tradeoff for instant boot. Quick one-shot Node VMs keep the smaller alpine-node rootfs plus the shared npm-cache.ext4 drive.
- Runtime — Alpine 3.21 + Node.js 22 LTS + npm.
- Deployment — staff-side firecracker-ctl-net.
What it gives you
Features
Fastify stack baked
fastify, @fastify/cors, helmet, static, undici, zod, pino, dotenv, nanoid and more resolved into /usr/lib/node_modules.
Network-ready
ca-certificates, iproute2, and /etc/resolv.conf pointing at 1.1.1.1 and 8.8.8.8 for TAP networking via Gluetun/WireGuard.
cp-entrypoint stage image
Multi-stage Docker build whose final layer ships a cp entrypoint so an in-cluster stage Job copies /rootfs.ext4 onto the rootfs PVC.
Boot init
/init mounts /proc /sys /dev, brings up lo + eth0, exports NODE_PATH, then exec /entrypoint.
Rootfs & ecosystem
Overview
Overview
Section titled “Overview”Fastify-ready Node rootfs used by the staff-side Firecracker deployment (firecracker-ctl-net). Built as a multi-stage Docker image whose final layer (alpine 3.21 + /rootfs.ext4) ships a cp entrypoint so the in-cluster stage Job can run the image directly and copy /rootfs.ext4 onto the firecracker rootfs PVC.
This is the long-lived deploy rootfs for Node endpoints submitted through the dashboard IDE — week-to-month TTL VMs where paying a build-time npm install is the right tradeoff for instant boot. Quick one-shot Node VMs keep the smaller alpine-node rootfs plus the shared npm-cache.ext4 drive.
What’s baked in
Section titled “What’s baked in”- Alpine 3.21 + Node.js 22 LTS + npm
fastify,@fastify/cors,@fastify/helmet,@fastify/static,undici,zod,pino,pino-pretty,dotenv,nanoid,date-fns,commander,chalkresolved into/usr/lib/node_modulesca-certificates-bundle,ca-certificates,iproute2/etc/resolv.confwith1.1.1.1and8.8.8.8/initmounts/proc,/sys,/dev, brings uplo+eth0, exportsNODE_PATH=/usr/lib/node_modules, thenexec /entrypoint
Ecosystem
Section titled “Ecosystem”| Image | Runtime | Deployment | Network | Server lib baked |
|---|---|---|---|---|
alpine-python | Python | firecracker-ctl (public quick) | none | no |
alpine-node | Node | firecracker-ctl (public quick) | none | no |
firecracker-python-net | Python | firecracker-ctl-net (staff, short-lived) | TAP via Gluetun/WireGuard | requests/httpx |
firecracker-python-web | Python | firecracker-ctl-net (staff, long-lived) | TAP via Gluetun/WireGuard | FastAPI |
firecracker-node-web (this) | Node | firecracker-ctl-net (staff, long-lived) | TAP via Gluetun/WireGuard | Fastify |
Build & publish
Build & publish
npx nx run firecracker-node-web:containernpx nx run firecracker-node-web:extractOutput: packages/docker/firecracker/node/web/dist/node-web.ext4.
Publish
Section titled “Publish”npx nx run firecracker-node-web:container:productionPushes ghcr.io/kbve/firecracker-node-web:latest and :<version>.
Questions
Frequently asked
What is the Firecracker Node Web rootfs?
It is a Fastify-ready Alpine 3.21 + Node.js 22 LTS rootfs used by the staff-side Firecracker deployment (firecracker-ctl-net). It is built as a multi-stage Docker image whose final layer ships a cp entrypoint so an in-cluster stage Job copies /rootfs.ext4 onto the firecracker rootfs PVC.
Why bake npm dependencies into the image?
This is the long-lived deploy rootfs for Node endpoints submitted through the dashboard IDE, running week-to-month TTL VMs. Paying a build-time npm install is the right tradeoff for instant boot, so fastify, undici, zod, pino, and the @fastify ecosystem ship already resolved into /usr/lib/node_modules.
When should I use alpine-node instead?
Quick one-shot Node VMs use the smaller alpine-node rootfs plus the shared npm-cache.ext4 drive. Use firecracker-node-web only for long-lived staff endpoints that benefit from pre-baked server libraries.