Every change gets
a place to click.
Open a pull request and a complete, private copy of your app is waiting a moment later — database and all, at its own link. Your team reviews the change instead of imagining it, and nobody queues for staging again.
Illustration: a pull request opens, an environment becomes ready, and a link is shared. A browser window shows a running copy of the application at its own address, marked live, with three reviewers having opened it.
One platform, not eight.
Everything an application needs between a commit and a URL, in one place and under one bill. Connect a repository once and every push after that deploys on its own.
Compute
CPU and memory for the thing you are running, sized per workload rather than per node you have to keep alive.
Containers
The image your CI already builds, unchanged. No rewrite into someone else's manifest format to get it running.
PostgreSQL
A real database as part of the application, not an external service you provision separately and wire in by hand.
Storage
Object storage for what the application writes and serves — uploads, artifacts, the files that outlive a single request.
Volumes
Block storage attached to a workload, for the state that has to survive a restart and belongs next to the process using it.
Networking
Private networking between services, and an HTTPS URL on the public side minted on request rather than configured.
Deployments
Connect a repository and a push becomes a deployment: built, rolled out and reachable without a pipeline to write first.
Environments
The whole set above, together, as one unit you can create per branch, per pull request or per customer.
A console that answers, a CLI, and an MCP server.
Three ways into the same platform. Deploy, manage, troubleshoot and operate from whichever one you are already in.
AI console
Ask why a deploy failed or what a service is doing, and get the answer from the platform's own state. It can propose the fix and carry it out.
CLI
The same operations from a terminal or from CI, scriptable, for the work that belongs in a pipeline rather than in a browser tab.
MCP server
Your own coding agent, connected to the platform directly — deploying and debugging against real infrastructure instead of guessing at it.
Your environment is yours alone.
Every environment runs in a space of its own, with its own database and its own address. Nothing you run can reach another customer’s work, and nothing of theirs can reach yours. Put realistic data in a preview and send the link to a colleague without wondering who else is on the machine.
Sealed off by default
Separation is not something you configure and hope you got right. Every environment is created isolated, and there is no setting that makes it less so.
Your data stays yours
The database and the files belong to that one environment. They are not a shared service with your rows in someone else’s table.
Gone when you are done
When an environment expires, everything inside it goes with it. Nothing lingers on a disk somewhere waiting to be found later.
Reviewing us for your security team? Ask for the architecture detail and we will walk you through exactly how the separation works.
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.app.domineta.com |
| pr-479-acme | preemptible | Provisioning | — | pr-479-acme-c0d41e77.app.domineta.com |
| nightly-e2e | standard | Expiring | 00:10:02 | nightly-e2e-acme-2b41f8d0.app.domineta.com |
| 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.
Deploys itself on every push
Connect a repository and turn on auto-deploy: a push to the branch you chose builds the image and rolls it into the environment, on the hostname that was already on the pull request. Off by default, and per environment.
Ask Domineta AI about a deployment
Ask why a build failed or what an environment is doing, in the Console. It can propose the work too — create, build, deploy, fix, extend, suspend, resume or delete — and each proposal is a button you press, never something it does behind you.
Describe it once. Get a URL immediately.
Bring the image your CI already builds, or connect a repository and let Domineta build it. Either way the environment is described by one file, and the URL is minted before anything has booted.
Describe
What your app needs to run, and how long you want it for. One file, or a short form.
Allocate
We find it a private space of its own and get it started. You do not size anything.
Run
Everything comes up together and you get a secure link you can share straight away.
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.
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.
- No region picker
- You do not choose where an environment runs, and 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.