Contribute

AIec is Apache 2.0 and the whole system is in this repository. Building it needs a Linux host with KVM, PostgreSQL and an S3-compatible object store. Below is what actually works, verified against the current tree.

Setup

git clone https://github.com/fedoragobrowse-design/AIec
cd AIec
cargo build --workspace --all-features

Check your prerequisites before anything else. aiec doctor reports the operating system, the runtime, the Bubblewrap and Docker binaries, /dev/kvm, the Firecracker binary and kernel, the guest artifact and the database configuration. It reports; it does not configure a cluster, and it does not verify the guest image digest, probe object storage or check TLS.

The gate

Every change passes the same four checks. This is the whole gate:

cargo fmt --all --check
cargo clippy --workspace --all-features --all-targets -- -D warnings
DATABASE_URL=postgresql://user:pass@127.0.0.1:5432/aiec \
  cargo test --workspace --all-features
python3 scripts/check-sdk-contract.py

The database-backed tests are real tests against a real PostgreSQL instance — they do not skip when the URL is absent, they just fail. The Python suites are separate and also part of the gate:

(cd sdk/python && python3 -m pytest tests/ -q)
(cd benchmarks && python3 -m pytest tests/ -q)

The website is a small static builder with no dependencies:

python3 web/build.py

The crate map

There is also a Python SDK under sdk/python and the benchmark harness under benchmarks.

Conventions worth knowing

• Migrations are append-only. Once a migration has been applied anywhere, do not edit it — not even trailing whitespace, because the checksum is verified. Add a new one.
• Tenant scope belongs in the query, not in a check afterwards. Every tenant-scoped lookup filters by tenant and id together.
• Unbounded reads are defects. List routes paginate with a stable keyset cursor and push the limit into the database.
• Evidence is committed. Acceptance and benchmark results live as JSON under benchmarks/, and the website's published numbers are reviewed by hand rather than regenerated.

Open work

The project keeps a running list of what is known to be wrong or missing, in docs/known-defects.md, and what is intended next, in docs/ROADMAP.md. Both are written to be useful to a new contributor rather than as a private notebook.

Work that is genuinely open and well-scoped:

• Second isolation provider. The e2b runtime is implemented but the least exercised. Live acceptance evidence for it does not exist.
• Network-enabled Firecracker. The worker lacks the capability to create a TAP device, so microVM runs are exercised with networking off. Closing this is the single most valuable piece of work for the isolation story.
• Storage byte quotas. CPU and memory are enforced; aggregate storage ceilings are designed but not implemented.
• Per-run pagination. Run-scoped event, attempt and artifact reads are still complete reads. The measured cost is small today, but the bound is absent rather than holding.
• aarch64. Cross-build evidence only — no hardware, no runtime, no performance claim.

Security reports