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.
The first working instance of this design is CILaaS — Cloud Innovation Lab as a Service: prepaid, governed Google Cloud lab projects for AI, Data, Networking, Security, DevOps and more. Browse the service catalog, start a time-boxed lab, and watch the lifecycle below play out end to end. Labs are the first environment type it delivers; the same engine can provision any environment from a specification. It runs as a development environment — deliberately a prototype and proof of concept.
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.
Innovation labs are only one use of this pattern. Ainova Digital offers Cloud Environment as a Service: you provide the environment or technical specification, and we design, provision and operate the matching cloud environment — on GCP, Azure or AWS, governed and cost-controlled by design. That could be a training or innovation lab, a proof-of-concept sandbox, a development or test environment, or a project-specific landing zone. CILaaS is the working prototype that proves the approach.
Target cloud(s), organisation or tenant structure, regions, networking and identity integration the environment must sit within.
The services, tooling and reference architecture required — AI, data, security, DevOps or application stacks — as technical specifications or blueprints.
Who gets access, for how long, and against which budget or prepaid balance — from time-boxed sandboxes to long-running environments.
Access policies, allowed services, tagging, data-handling and audit requirements the environment must be governed by.
The control plane (portal, API, ledger, orchestrator) is built once and stays small; the workload plane is created per environment from your specification. That boundary keeps the design portable across clouds and customers.