Firework

Firework turns a "git push" into running Firecracker microVMs. The isolation of a VM, the UX of a container, and all without Kubernetes complexity

Comment

Inspiration

Firework came out of a few things coming together:

  • I was interested in Firecracker microVMs but never had time to actually play with them. It was clear to me this would become a trendy topic given the rise of AI workloads.
  • I was curious to see how much AI coding agents could actually help with a project like this.
  • I use Kubernetes at work, and while it's a great tool, it can be quite complex to operate. I wanted to see how hard it would be to build something more lightweight.

It's also worth mentioning that AWS recently announced Lambda MicroVMs, which is similar in functionality to Firework. That underscores how important this kind of technology for AI workloads.

What it does

Firework orchestrates Firecracker microVMs, making them much easier to run.

A git push turns into a running Firecracker microVM: the isolation of a VM, the UX of a container, and all without Kubernetes complexity.

How I built it

I started building Firework in January 2026 in my free time, and made the repo public on February 23. Initially it contained a working version tested on AWS.

It took me around one week in total (combining evenings and weekends) to get from the first commit to a system that actually worked on AWS. I actively used AI agents throughout the process, and I consider it a real success. Doing this the old-fashioned way could easily have taken a couple of months.

That same AI-assisted workflow carried into OpenAI Build Week itself: over the weekend of July 18–19, I used Codex and GPT-5.6 models to add a deployment status API/UI/CLI and persistent local volume support to Firework, plus two smaller ones (https://github.com/artemnikitin/firework/pull/34 and https://github.com/artemnikitin/firework/pull/35). That took 2 days with AI help vs a month (or maybe more) building it the old-fashioned way. And it was just about $150 in token costs.

Challenges I ran into

The biggest challenge, still true today, is that Firecracker won't run on macOS (it needs /dev/kvm), so testing requires a real Linux machine with nested virtualization support. On top of that, testing the networking side properly needs at least two machines.

I ended up spinning up real infrastructure on AWS/GCP and testing there. It works, but it makes iteration slow and occasionally flaky: bringing infra up from scratch takes 30–60 minutes and can fail for reasons outside my control (capacity limits, transient cloud service issues, etc.).

Accomplishments that I'm proud of

Being able to build a system this complex (including infrastructure provisioning pieces) in about a week of actual working time.

What I learned

Complexity

  • Infrastructure-as-code dependency graphs don't guarantee a real orchestration timing.
    Terraform can start launching EC2 instances in parallel with the NAT gateway that gives them internet access, so the very first outbound network call a new node makes can fail before its network path even exists. This is a race condition that's invisible until you watch a region come up from a cold start.
  • Networking has hidden asymmetries.
    The 2 services can reach each other fine when placed on different nodes, but if the scheduler later happens to colocate them on the same node, that same connection can silently break, because traffic forwarded to a host's own public address doesn't loop back the way you'd expect.

Corner cases

  • A fresh heartbeat from an agent isn't proof it applied the latest configuration.
    An agent can report "I'm alive" while still describing an older, already-superseded revision, so status reporting has to fail closed until desired, placement, and applied state all agree.
  • A microVM that survives an agent crash or restart has to be safely recognized and reclaimed.
    A reused operating-system process ID is never proof by itself that the original process is still the one you think it is.

What's next for Firework

Near-term, I'm finishing the lifecycle fundamentals:

  • durable VM adoption after an agent restart
  • explicit empty-state handling
  • richer applied-revision/condition reporting

After that:

  • shared persistent volumes across nodes with proper single-writer safety
  • node-type-aware scheduling
  • and closing out the same-node networking edge case mentioned above.

Longer-term, I want to build toward the AWS Lambda MicroVMs use case directly: on-demand, pausable, resumable microVM sessions, plus Azure support and the rest of the roadmap tracked in the https://github.com/artemnikitin/firework/issues.

Built With

Share this project:

Updates