Build an ephemeral AI code sandbox with Firecracker on Arm
Introduction
Understand the sandbox architecture
Prepare the Arm KVM host
Run code in a disposable microVM
Validate the execution boundaries
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Introductory
Reading time:  45 min
Last updated:  29 Sep 2026
Skill level:
  Introductory
Reading time:
  45 min
Last updated:
  29 Sep 2026
Author:Pareena Verma, Arm
Arm IP:Neoverse
Tags: Containers and Virtualization Arm AGI CPU AWS Graviton Linux Firecracker KVM Bash
Author:
  • Pareena Verma, Arm
Arm IP:
Neoverse
Tags:
Containers and Virtualization Arm AGI CPU AWS Graviton Linux Firecracker KVM Bash

Who is this for?

This Learning Path is for developers who want to isolate AI-generated code in disposable microVMs on an Arm Linux server.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Prepare an Arm Linux kernel-based virtual machine (KVM) host and an aarch64 Firecracker guest image.
  • Run generated shell code in a dedicated disposable microVM.
  • Apply CPU, memory, timeout, filesystem, and network boundaries to each execution.
  • Verify native Arm execution and confirm that guest filesystem changes don't persist.

Prerequisites

Before starting, you will need the following:

  • An Arm AGI CPU platform or another Arm-based bare-metal server, such as an AWS Graviton4-based bare-metal instance, running Ubuntu 24.04 with KVM available as /dev/kvm
  • Root or sudo access on the server
  • Familiarity with Bash, SSH, and Linux networking
  • Outbound internet access to download Firecracker and guest artifacts

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll build an ephemeral Firecracker microVM sandbox for generated shell code on an Arm Linux KVM host. First, you’ll examine the per-job isolation model, then install Firecracker and prepare a reusable aarch64 guest image. Next, you’ll run a sample program with bounded CPU, memory, execution time, disposable filesystem state, and restricted networking. Finally, you’ll verify filesystem disposability, timeout behavior, and cleanup of per-job network and runtime resources.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
How do I confirm that KVM is available before I start?
Check that /dev/kvm exists on your Arm host. If you use a VM, ensure that it exposes nested virtualization and passes /dev/kvm through. Otherwise, use an Arm-based bare-metal server.
What does the sandbox runner download, and where does it go?
The runner downloads 00-common.sh, run-job.sh, and demo.sh into sandbox/, and the example programs hello-arm.sh, write-marker.sh, and timeout.sh into sandbox/examples/.
What result should I expect when I run an example job?
You should see the runner start a Firecracker microVM and execute the selected script inside the guest. For the default example, confirm architecture=aarch64, cpus=1, outcome=succeeded, and exit_code=0. The kernel version and job identifier can vary.
How do I know that guest filesystem changes don’t persist between jobs?
Run write-marker.sh twice. Each job checks for /tmp/ai-sandbox-marker before creating it. Confirm that the second job doesn’t find the marker from the first job, because each job starts with a fresh copy of the base image.
How do I confirm network and runtime cleanup after a job finishes?
After the job exits, confirm that the fc-ai0 TAP device is absent and that /opt/firecracker-ai/runtime contains no job directories. The reusable runner.lock file remains in the runtime directory.
Next