Ephemeral VMs
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
In Takumi Runner, all workflow jobs run on dedicated ephemeral (disposable) VMs. This page explains the definition of ephemeral VMs and the isolation model.
What Is an Ephemeral VM
An ephemeral VM is a virtual machine that is newly created for each job execution and automatically destroyed upon completion. Each VM has its own independent kernel, filesystem, and network stack, with no state shared between jobs.
As shown in the following diagram, even when multiple jobs are running, each is guaranteed to be assigned to a different VM.
This "1 job = 1 VM" model guarantees:
- Files and processes left by previous jobs do not affect subsequent jobs
- Credentials and tokens obtained during job execution are destroyed along with the VM
- A compromised job is unlikely to spread to other jobs
While ephemeral VMs eliminate state sharing at the VM level, compromise between jobs can still occur through GitHub-side shared caches, such as Cache Poisoning. Ephemeral VMs strengthen runner environment isolation but do not completely eliminate risks stemming from shared resources on the GitHub Actions platform.
Isolation Boundary
Ephemeral VM isolation consists of the following layers:
| Layer | Isolation |
|---|---|
| Kernel | An independent Linux kernel boots per VM |
| Filesystem | An independent root filesystem is assigned per VM |
| Network | An independent network namespace and virtual NIC are assigned per VM |
| Processes | Processes in one VM cannot see processes in other VMs |
Container-based isolation shares the host OS kernel, creating risk of escape through kernel vulnerabilities. With VM-level isolation, an independent kernel boots per job, making escape to the shared infrastructure (host) relatively more difficult.