Ephemeral environments
with a real kernel boundary.
Run a complete dev or test environment inside its own microVM, with its own guest kernel. Your image, unchanged. An HTTPS URL the moment you ask for one — and a TTL that throws the whole thing away.
boundaryA separate guest kernel, so a container escape lands the attacker inside their own kernel, not on the host.
Diagram: an Orkastor environment. Inside one microVM sit three services — web on port 8080, api on port 3000, and an internal-only postgres — above a guest kernel belonging to that environment alone. Below the microVM boundary is the bare-metal host and its own separate kernel, on machines kept for customer work alone.
Every environment gets its own kernel.
Most platforms in this space put your code in a container next to everyone else's, sharing one host kernel. That is a namespace, and a namespace is a scheduling construct — it was never designed to hold against code that is actively trying to leave.
Two guest kernels, independent of each other and of the host's. Each environment's system calls are served by a kernel that only that environment is running in.
Diagram: two environments side by side. Each contains its application and its own guest kernel inside its own microVM. Both sit above bare metal whose host kernel neither of them reaches.
Kata Containers, on metal we operate
A virtual machine with its own kernel, on bare metal we keep for customer work and nothing else. Our own services never run on the same machines.
Trial and Dev plans use gVisor
Those two plans run under gVisor — a userspace kernel on ordinary compute. A real boundary, and a weaker one than a separate guest kernel. We would rather name that difference than average it away into one word.
Everything else follows from that line. An ephemeral Postgres is isolated by the same boundary as the web process in front of it — not by a second mechanism bolted on for databases.
A whole environment, not a container.
A frontend, an API and a real datastore, started together, addressed on one hostname and thrown away together. The Console is where they live.
| Environment | Tier | Status | TTL | URL |
|---|---|---|---|---|
| pr-482-acme | standard | Running | 08:00:00 | pr-482-acme-7f3a9c21.orkastor.cloud |
| pr-479-acme | preemptible | Provisioning | — | pr-479-acme-c0d41e77.orkastor.cloud |
| nightly-e2e | standard | Expiring | 00:10:02 | nightly-e2e-acme-2b41f8d0.orkastor.cloud |
| agent-sandbox-3 | preemptible | Suspended | paused |
A provisioning environment already has its URL — the hostname is issued when you ask for the environment, not when it finishes starting. Until the first deploy succeeds it serves a holding page, which is exactly why it can go on the pull request straight away.
Multi-service, one hostname
Your frontend, API and database share one address, so the frontend calls
/api directly. No CORS to configure, and the same build works in
every environment.
Datastores inside the boundary
Run Postgres or Redis alongside your application. Databases stay private to the environment — we will not put one on the public internet even if you ask, because that is how test data ends up on the news.
Services find each other
Each service can reach the others by name, and the addresses arrive as environment variables. Nothing to wire up, and your own settings are never overwritten.
Describe it once. Get a URL immediately.
Bring the image your CI already builds, or connect a repository and let Orkastor build it. Either way the environment is described by one file, and the URL is minted before anything has booted.
Describe
Services, ports, a TTL and where each one is reachable. One file, or the create form.
Allocate
A microVM is scheduled onto the tenant node pool and its guest kernel boots.
Run
Services start, routes attach, TLS is terminated at the gateway.
Reclaim
The TTL expires, you get a grace window, then the whole environment goes.
Environments that shouldn't become infrastructure projects.
Pull request environments
Give every PR its own complete environment, with a URL you can paste into the description before CI has finished.
Integration testing
Frontend, API and a real database together, seeded and torn down per run, instead of one shared staging everybody queues for.
Agent-generated code
Somewhere for a coding agent to actually run what it wrote. The boundary matters more when nobody read the code first.
Development sandboxes
A temporary environment for a spike or a demo that does not leave anything behind in shared infrastructure.
A different boundary.
Not a scorecard against a named competitor — a comparison of two architectures, either of which can be the right one.
| Property | Container environment | Orkastor environment |
|---|---|---|
| Isolation | Namespace on a shared kernel | microVM |
| Kernel | Shared with the host | Its own guest kernel |
| Unit | A container | The whole environment |
| Datastore | External, or an add-on | A service inside the boundary |
| HTTPS URL | Usually configured | Minted on request |
| Lifetime | Persistent, or varies | Ephemeral, on a TTL |
Designed with boundaries.
These are decisions, not gaps waiting to be filled. Better to know now than to find out at the wrong moment.
- Environments expire
- Every one has a time to live, a grace period, and then it is gone. That is the product, not a limitation of it.
- Nothing is kept
- Storage goes when the environment goes, database included. There are no backups to restore from, so seed with test data.
- One region
eu-north-1, with no region picker. Your own domains are not supported yet either.- No GPUs
- Not in the first version, and neither is networking between separate environments.
- The first one is slow
- We scale the hardware to zero when nobody is using it, so the first environment after a quiet spell can take five to twenty minutes. The rest are quick.
Being built in the open.
We would rather publish the right number once than publish one twice, so there is no rate card here yet. When there is, it will be because it was measured.
Give every environment
a real boundary.
Build it.
Test it.
Throw it away.