Loading…
Topic
Firecracker
7 posts about Firecracker. Every summary links to the original.
- 7 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Fly Kubernetes does more now
Fly Kubernetes is moving from early access to a closed beta as a managed Kubernetes service backed by Fly.io infrastructure. It provides the Kubernetes API while mapping core primitives to Fly resources: containers become Firecracker microVMs through flyd and Firecracker, pods become Fly Machines, networking uses an internal WireGuard mesh, services use the Fly Proxy, and storage uses Fly Volumes. Virtual Kubelet, running alongside K3s, receives pod requests and deploys them through the Fly Machines API, removing user-managed node capacity planning and hardware management. The beta supports workloads, including GPUs, across available regions, with Deployments/ReplicaSets, Services, DNS, and ephemeral and persistent volumes, but only part of the Kubernetes API. Missing capabilities include multi-container pods, StatefulSets, network policies, horizontal pod autoscaling, and emptyDir volumes; pricing is free during beta and planned at $75 per cluster monthly afterward, excluding resource costs.
Fly Machines: an API for fast-booting VMs
Fly Machines are virtual machines exposed through a fast REST API, with boot times of about 300ms, intended to support cost-effective standby capacity and scale-to-zero applications. Creation is deliberately separated from starting: it performs a centralized database preflight, reserves host capacity through NATS, records the machine, and prepares the OCI image locally. A later start request goes to the nearest regional API, which sends a direct message to the known host, avoiding database coordination and image pulls; examples cite roughly 10ms locally and 150ms across regions. Processes can exit when idle to leave machines intact for clean restarts, while fly-proxy can start them for incoming HTTP requests. The design trades simplicity for hardware pinning, so capacity or host failures may require fallback machines and redundancy; stopped machines currently incur image-storage charges, such as about $0.15 per month for a 1GB Docker image.
Docker without Docker
Fly.io explains how it accepts OCI container images while avoiding Docker at runtime, choosing Firecracker micro-VMs because Docker’s isolation is not strong enough for its high-density multitenant environment. It describes OCI images as ordered tarball layers, showing how registry authentication, manifests, architecture selection, blob downloads, and configuration data are enough to reconstruct a container filesystem and entrypoint. On the platform side, flyctl uses Docker’s client library to push images, while a custom Go repository server adds token-based authorization, repository rewriting, and handling for cross-repository blob mounts and registry state. Servers use containerd as a cache over an LVM2 thin pool, leases and copy-on-write snapshots to provision VM filesystems quickly, and a Rust init configures mounts, networking, DNS, SSH, and the entrypoint before Firecracker runs the workload.
Fly In 2020 - A year in features (and articles)
Fly’s 2020 retrospective covers the launch and expansion of its Global Application Platform, alongside features and articles released throughout the year. The platform added Turboku for moving Heroku apps to the edge, Cloud Native Buildpack support, Custom Domains with a GraphQL management API, scaling controls, Deno support, pausing and resuming, persistent volumes, and builtin Flyctl builders for Node, Ruby, Deno, Go, and static websites. Later additions included a new logging system, 6PN Private Networking, WireGuard peering, graceful VM shutdown options, and revised VM sizes, while examples demonstrated services such as Redis, MinIO, Gogs, and MQTT using persistent volumes. The article also records supporting work including GoStatic, JSON output in Flyctl, Firecracker-based workload isolation, and Heroku database usage.
We cut bandwidth prices. Go nuts.
Fly.io announces lower outbound data-transfer pricing for apps running in its Firecracker VMs: $0.02 per GB from North America and Europe, and $0.04 per GB almost everywhere else. The December 1, 2020 change follows dramatically increased volume, reducing bandwidth costs by 75% from the March launch prices of $0.085 per GB in North America and Europe and $0.14 in Asia Pacific. Rather than use graduated tiers or regional rates, Fly.io uses one blended price for all customers, accepting that some traffic is more expensive and some use cases may pay too much. A 70% target margin underpins the model, while a 160GB monthly free allowance covers low-volume projects; India is an exception at $0.12 per GB, and large-transfer customers can request lower prices if they commit to substantial monthly usage.
BPF, XDP, Packet Filters and UDP
Deploying unmodified UDP applications across an anycast edge and worker network is harder than proxying HTTP, because UDP carries no convenient metadata for forwarding the original socket addresses. The initial implementation used userland services, AF_PACKET sockets, and custom proxying, but the post argues that kernel-level packet handling is a better fit than adding and monitoring another service. It explains BPF’s evolution into eBPF, then describes using XDP for fast ingress processing, XDP_REDIRECT around WireGuard limitations, and TC BPF on the worker side; Firecracker tap devices make reply traffic appear as host ingress. The verifier requires bounds checks and debugging benefits from dropwatch and perf-based packet tracing. The result is a beta deployment path for UDP applications on Fly.io.
Sandboxing and Workload Isolation
Workload isolation makes it harder for a vulnerability in one service to compromise the rest of a platform, and becomes especially important when hosting other people’s code. The post surveys isolation mechanisms from chroot and privilege separation through namespaced containers, mandatory access control, seccomp-bpf, capabilities, and language runtimes, before considering virtualized approaches. It emphasizes that network exposure is often the most consequential attack surface, while chroot alone leaves access to ptrace, procfs, device nodes, and networking. Firecracker is presented as the selected VMM: a small Rust implementation that limits itself with seccomp-bpf and runs under an external jailer providing chroot, namespaces, and dropped privileges. The closing menu includes nsjail, unprivileged Docker with tighter filtering, gVisor, and Firecracker or Kata; absent hostile code, the author would tune nsjail for return on investment.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.