Network Alpine Python rootfs forFirecracker
A network-capable Alpine 3.21 + Python 3.12 Firecracker rootfs for the staff-side firecracker-ctl-net deployment — baking requests, httpx, certifi, the CA bundle, and public DNS for short-lived networked VMs.
The networked opposite of alpine-python
The alpine-python rootfs used by public quick-mode firecracker-ctl VMs ships with no network, no DNS, and no requests — sandboxing without egress is the safety property. This image is the opposite: TAP networking via Gluetun/WireGuard, DNS, and HTTP libraries baked in for the staff persistent deployment.
- Runtime — Alpine 3.21 + Python 3.12.
- Deployment — staff-side firecracker-ctl-net.
What it gives you
Features
HTTP stack baked
py3-pip, py3-requests, py3-httpx, py3-urllib3, py3-certifi ship already resolved so VMs boot with the client libraries on disk.
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 Alpine 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, then exec /entrypoint.
Rootfs & ecosystem
Overview
Overview
Section titled “Overview”Network-capable Python rootfs image 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 image is not for the public sandbox quick-mode VMs. Those keep the no-network alpine-python rootfs from apps/vm/firecracker-ctl/rootfs/Dockerfile.alpine-python — sandboxing without internet egress is the safety property.
What’s baked in
Section titled “What’s baked in”- Alpine 3.21 + Python 3.12
py3-pip,py3-requests,py3-httpx,py3-urllib3,py3-certifica-certificates-bundle,ca-certificates,iproute2/etc/resolv.confwith1.1.1.1and8.8.8.8/initmounts/proc,/sys,/dev, brings uplo+eth0, thenexec /entrypoint
Two ecosystems
Section titled “Two ecosystems”| Image | Deployment | Network | DNS | requests baked |
|---|---|---|---|---|
alpine-python (existing) | firecracker-ctl (public quick) | none | no | no |
firecracker-python-net (this) | firecracker-ctl-net (staff persistent) | TAP via Gluetun/WireGuard | yes | yes |
Build & publish
Build & publish
npx nx run firecracker-python-net:containernpx nx run firecracker-python-net:extractOutput: packages/docker/firecracker/python/net/dist/python-net.ext4.
Publish
Section titled “Publish”npx nx run firecracker-python-net:container:productionPushes ghcr.io/kbve/firecracker-python-net:latest and :<version>.
Questions
Frequently asked
What is the Firecracker Python Net image?
It is a network-capable Alpine 3.21 plus Python 3.12 rootfs image for the staff-side firecracker-ctl-net deployment. It bakes in requests, httpx, urllib3, certifi, the CA-certificates bundle, and a resolv.conf pointing at public DNS.
How is Firecracker Python Net different from alpine-python?
The alpine-python rootfs used by the public quick-mode firecracker-ctl VMs ships with no network, no DNS, and no requests, keeping sandboxes egress-free. Firecracker Python Net is the opposite, with TAP networking via Gluetun/WireGuard, DNS, and HTTP libraries baked in for the staff persistent deployment.
How is the Firecracker Python Net rootfs built and delivered?
It is a multi-stage Docker image whose final Alpine layer ships a cp entrypoint, so an in-cluster stage Job runs the image directly and copies /rootfs.ext4 onto the firecracker rootfs PVC.