Ainova Cloud Labs turns a catalog click into a live, working cloud environment — and turns the end of a session into a clean, automatic teardown. This page shows the proof-of-concept build: real provisioning, real guardrails, real credit accounting, running on whichever cloud a request is configured to land on.
Every "Start Lab" click walks the same path, whichever cloud it lands on — across one real trust boundary between what's always running and what exists only for the length of your session.
Browse the catalog and choose an experiment — no ticket, no approval queue.
The API checks your tier and credit balance before anything is reserved.
The orchestrator applies the platform's guardrails and decides which cloud the lab will live on.
A time-boxed, budget-capped sandbox is provisioned on that cloud, tagged so it can never be mistaken for anything else.
The lab reports ready, and you work through the guided exercise hands-on.
When the clock runs out — or you clean up first — the sandbox tears itself down and unused credit comes back.
Six mechanisms carry the whole promise above. None of them are optional, and none of them depend on someone remembering to turn a lab off.
Eleven technology tracks, from generative AI to networking, each with a guided experiment and an honest, pre-shown cost estimate.
Every account carries a prepaid credit balance. A lab simply can't start if the tier doesn't allow the service, or the balance can't cover it.
Each sandbox gets an access policy that can build and inspect its own resources — and nothing else. Not billing, not identity, not its own leash.
A background sweep checks every lab hourly against its own expiry clock, and its actual spend every 15 minutes — whichever trips first wins.
A chat copilot grounded in the real catalog can recommend a tier or explain a running lab. It can propose starting one — never spend a credit itself.
The same catalog, credit ledger, and guardrail logic sit behind one adapter. Azure, AWS, or GCP is a configuration choice, not a rewrite.
The control plane is the part that never stops running: identity, the catalog, the credit ledger, the orchestrator. It's small, changes rarely, and is deployed once. The workload plane is everything created for a single lab request — and it's the opposite in every way: created fresh, isolated by tag and policy, and deleted the moment it's no longer needed.
The diagram above draws that line deliberately. Crossing it — from a standing API call into a disposable sandbox — is the one moment the whole design exists to get right.