Limitations
The page that would be missing from a launch if the launch were being written for advertising. These are the properties AIec does not claim, the measurements that were never taken, and the places where the proof is a unit test rather than a recorded deployment.
Not measured at all
These are not weak results. They are questions the project has not answered, and it would be misleading to imply otherwise.
- Network-enabled Firecracker. The worker still lacks the capability to create a TAP device, so microVM runs are exercised with networking switched off. Every Firecracker measurement on this site is a no-network measurement.
- The hosted isolation provider.
RuntimeKind::Hostedexists in the code and is not exercised against a real provider. No live evidence for that path exists anywhere. - Repository cache on Firecracker or a hosted runtime. The cache was rejected on its own numbers on Docker; it was never carried to the other substrates.
- PID-namespace isolation. No artifact asserts it. The only namespace fact recorded anywhere is Guard's: a fresh user and network namespace, a recorded host inode that differs, and no external interface.
pressure.observed_atstaleness. Accepted and unproven. Admission actually gates onlast_heartbeatfreshness, which is the documented contract, so this is a gap in the resource-pressure signal rather than in the admission path.- aarch64. Cross-build evidence only. No hardware, no runtime, no performance claim.
Thin evidence
Firecracker latency
Three samples. The harness deliberately withholds p50, p95 and p99 below twenty samples, and this page follows that rule rather than printing percentiles from three runs. What exists is a live proof that the path works — rootfs copy-on-write, guest destruction, lease release — not a throughput claim.
Guard overhead
Seven paired samples over a local HTTP connection. Excludes the guest, the nftables rules, the watcher and all control-plane cost. No confidence interval. It supports "policy evaluation is cheap on this hardware", not a general performance statement.
Constraints that are by design
Refusal under capacity
When every worker is at measured capacity, placement is refused. Three of eighty runs in the final parallel soak were refused this way. That is the admission gate working, but those three refusals have not been fully explained and are not counted as a clean sweep.
No silent spillover
AIec will not move a workload to a cloud provider when the local cluster is full. A failed request is a smaller problem than a workload that quietly changed isolation boundary or jurisdiction.
Guard needs privileges
A worker without CAP_NET_ADMIN advertises
network_policy: false and refuses governed placements rather
than running them ungoverned. Governed workloads are therefore unavailable
on a worker that was not set up for them.
Single-host tap allocation
Cross-process TAP address allocation is inventory-probe based and cannot be reserved atomically, so the network driver carries this limitation. It is recorded in the project's known-defects file rather than worked around.
Prose-only numbers
Some figures on the benchmarks page exist only in hand-written reports because no JSON artifact was committed for them. They are labelled as weaker evidence there. They are included because they describe work that really happened, not because they are as trustworthy as a harness run.
Every item here is also in the repository's own known-defects file, where it is tracked with more detail. Putting it on the site means a reader does not have to audit the source to discover the project's own limits — which is the only way the limits are worth anything.