Skip to content

SYSTEM Cited by 1 source

Atlassian Fireworks

Fireworks is Atlassian's internal Firecracker-microVM orchestrator on Kubernetes, the "secure execution engine behind Atlassian's AI agent infrastructure." It accepts an OCI container image + command and boots a hardware-isolated Firecracker VM to run the workload, with production features comparable to a public-cloud FaaS substrate.

(Source: sources/2026-04-24-atlassian-rovo-dev-driven-development)

Role

Fireworks is the execution substrate for Atlassian's agent platform — the place where untrusted / semi-trusted AI-agent workloads run, isolated from each other and from the surrounding Atlassian infrastructure. The architectural shape is the same as systems/fly-kubernetes (Firecracker micro-VMs exposed via the Kubernetes API / scheduler surface), applied internally to Atlassian's own agent-execution needs rather than as a public cloud offering. See concepts/hardware-isolated-microvm-on-kubernetes.

Feature surface

Verbatim from the source post:

"You submit an OCI container image and a command, and it boots a hardware-isolated Firecracker VM, runs your workload. Features include 100ms warm starts, live migration between hosts, eBPF network policy enforcement, shared volumes, and snapshot filesystem restore, sidecar sandboxes."

Feature What it means operationally
100ms warm starts Snapshot-based Firecracker boot into a prewarmed state; fast enough to be usable in interactive agent loops, not just batch. See concepts/cold-start.
Live migration between hosts VM-level state transfer between K8s nodes — tenants can be rebalanced without workload restart, enabling binpacking and host maintenance without tenant-visible disruption.
eBPF network policy enforcement In-kernel packet filtering applied to the guest VM's traffic; control-plane-declared policies are compiled to eBPF and loaded on the host, avoiding per-packet user-space cost.
Shared volumes Cross-VM data plane; multiple VMs (workload + sidecars) can see a common mount — the substrate for the sidecar-sandbox composition below.
Snapshot filesystem restore Forking a VM's filesystem state cheaply so a new VM can spin up from a frozen template or a checkpointed agent session.
Sidecar sandboxes Multiple micro-VMs co-located per workload (main + helper VMs) — a micro-VM analogue of the Kubernetes pod-sidecar model, but with hardware-isolation boundaries between containers.

Architecture (as described)

The post names the major internal components verbatim:

"To do this we had to build a scheduler, autoscaler, node agents, envoy ingress layers, raft persistence, and much more."

Expanded into the canonical orchestrator shape:

                  Developer / LLM agent
                         │
                         │ submit(OCI image, command)
                         ▼
             ┌───────────────────────┐
             │      Fireworks API    │ ◄─── Envoy ingress layers
             └───────────┬───────────┘
                         │
                  ┌──────┴──────┐
                  │  Scheduler  │ ◄─── Autoscaler
                  │             │
                  │  Raft-based │ ◄─── persistence for
                  │  replicated │      scheduler state &
                  │  state      │      placement decisions
                  └──────┬──────┘
                         │ place(VM, node)
                         ▼
         Kubernetes cluster (AWS scms shared)
                   ┌─────┴─────┐
                   │ Node agent│ ─── per-node lifecycle
                   └─────┬─────┘      (boot/snapshot/migrate)
                         │
                         ▼
               ┌───────────────────┐
               │ Firecracker µVM   │   hardware-isolation
               │   (guest OCI      │   boundary per workload
               │    workload)      │
               └───────────────────┘
                         │
                         ▼
                 eBPF network policy
                 (enforced in kernel on host)

Layer mapping:

  • Envoy ingress — systems/envoy as the front-door L7 proxy, likely terminating TLS and fanning requests to the Fireworks API.
  • Scheduler + Autoscaler — the control plane that decides which node runs which VM, and how many nodes to provision. Raft-backed so scheduler state survives a control-plane node loss.
  • Raft persistence — replicated log for scheduler / placement state, consistent with how Kubernetes-adjacent orchestrators typically model control-plane durability.
  • Node agent — per-host daemon that actually boots / snapshots / migrates Firecracker VMs, and handles local eBPF policy installation.
  • Firecracker µVM — systems/firecracker runs the guest OCI workload under KVM, providing the hardware-isolation boundary.

Substrate substrate

Fireworks runs on the shared AWS scms Kubernetes cluster — Atlassian's internal K8s platform. "Our meta-workflow / orchestration skill [...] a skill that automates deploying, operating, and tearing down isolated Fireworks dev shards on the shared AWS scms Kubernetes cluster." The dev-shard pattern is itself agent-aware: the agent can create and tear down whole isolated substrate environments for e2e testing, see patterns/dev-shard-iteration-loop.

Why Firecracker + Kubernetes

The composition is the same architectural move systems/fly-kubernetes makes: keep Kubernetes' scheduler / networking / declarative-API surface, but replace the container runtime with Firecracker so that workload isolation is hardware-enforced, not kernel-namespace- enforced. For agent-execution workloads this matters more than for typical application workloads — AI-agent code may be generated on the fly, may run tooling the platform owner has not audited, and may need to run alongside other tenants' agents on the same K8s node. Container-level isolation under such a threat model is a known-weak boundary; VM-level isolation is not. See concepts/micro-vm-isolation, concepts/server-side-sandboxing.

Production workflow that built it

The Fireworks post is as much about how it was built as about the system itself — the platform was "built in four weeks, entirely by LLMs" using:

Seen in

  • sources/2026-04-24-atlassian-rovo-dev-driven-development — introduction post; full feature surface + internal components + build-workflow retrospective. Fireworks is the reference production instance of the [[concepts/hardware-isolated-microvm- on-kubernetes]] shape on this wiki.
Last updated · 510 distilled / 1,221 read