Architecture
How Atlasflow runs deployment containers in microVMs
Each deployment container runs in its own Cloud Hypervisor microVM on a bare-metal host managed by Atlasflow. This page describes the isolation boundary, health checks, and placement model.
A separate guest kernel for each deployment container
Containers normally share their host's kernel. Atlasflow instead runs each deployment container inside its own Cloud Hypervisor microVM with a separate guest kernel. The physical host is still shared, but workloads do not share a host kernel or container namespace.
Applications run as containers and expose a web service that Atlasflow can check for health.
Atlasflow-managed bare-metal hosts
Atlasflow manages dedicated bare-metal servers, workload placement, and the microVM runtime on those hosts. Customer workloads do not run inside hyperscaler virtual-machine instances.
Compute hosts remain shared. Atlasflow manages CPU placement, limits, and host headroom.
Running instances are not started per request
Atlasflow keeps a running deployment instance available rather than invoking a new function for each request. A quiet period does not, by itself, cause a per-request platform startup.
CPU and memory are metered for running deployments by the second. Storage is metered while allocated, and traffic is billed by volume. There is no per-request charge.
Health-gated deployment
A new deployment receives production traffic only after its health check passes. If it never becomes healthy, it is marked failed and the latest successful deployment stays active.
Running instances are checked continuously. The control plane detects unhealthy instances and works to restore the declared state.
Capacity and placement
The control plane places each microVM on a host with available capacity and can distribute workloads across regions.
Replica and region options depend on the selected plan. The deployment model stays the same as capacity changes.
A container-based deployment model
Atlasflow builds a container image from a connected GitHub repository and runs it in a microVM. The application exposes a web service, and Atlasflow checks it before routing production traffic.