AIec

Public alpha status

What actually works today, and what does not. This page is deliberately blunt: an unexercised capability is never reported as working.

Working

CapabilityStatus
Firecracker microVM sandboxesWorking, exercised end to end
Docker runtimeWorking, trusted deployments only
Exec, stdin, environment, cwdWorking, bounded by time and output size
File read/write/list/deleteWorking, confined to the workspace
Coding guest imageWorking — Git, CA certificates, Python, curl, tar
HTTPS Git clone, edit, diffWorking, verified inside a real microVM
Workspace snapshotsWorking, portable between owners
PostgreSQL state, leases, quotasWorking
S3-compatible object storageWorking
Worker recovery and fencingWorking — reassignment at a higher generation, stale workers rejected

Limited

CapabilityLimitation
SignupInvite-only. No open registration during alpha.
CapacityLimited by the hosted provider's free allowance. When it is exhausted, creation stops with TEMPORARY_CAPACITY_UNAVAILABLE rather than overage.
SLANone. This is alpha software without a support commitment.
RegionsA single execution region during alpha.
API stabilityEndpoints may change before 1.0.
SnapshotsWorkspace archives are portable. VM memory snapshots are not.

Not yet implemented

Stated plainly so nobody plans around them:

Hosting model

Cloud execution is provided by a hosted sandbox provider with Firecracker-based isolation. AIec's own native Firecracker implementation is complete and is what self-hosted deployments run — but the hosted capacity is not AIec operating its own hardware. We report these separately rather than merging them into one claim.

ClaimStatus
AIec native Firecracker runtimeComplete and verified
Hosted Cloud execution capacityProvided by a third-party Firecracker provider
AIec-operated multi-host worker fleetNot deployed

Security posture

The full picture, including what is not yet enforced, is in SECURITY.md. Report a vulnerability to security@gobrowse.dev, not to a public issue.