How Autonoma Preview Environments Works

Most teams ship a preview URL and call it done. The build goes green. The PR sits in review. Nobody has actually verified whether the feature works against a real backend, real database state, or the queue that routes payments. Autonoma was built to close that gap without asking your platform team to build and maintain the infrastructure themselves.

Here is exactly what we built and how to start using it.

What Autonoma Is

Autonoma is a two-layer product designed for fast-growing startups shipping multiple PRs per day.

Layer 1 is managed preview infrastructure. When a PR opens, Autonoma provisions a complete isolated runtime: frontend, backend, database, queues, caches, and any background workers your app runs. Every service gets its own isolated container. The environment routes traffic correctly, receives secrets and config, mirrors production topology, and tears itself down when the PR closes. No infra overhead lands on your team.

Layer 2 is a three-agent E2E testing system (Planner, Automator, Maintainer) that runs automatically on every preview Layer 1 creates. The agents read your codebase, plan test cases, execute them against the real preview URL, and keep tests passing as your code shifts. Your codebase is the spec. No recording, no writing, no maintenance.

The two layers run together. Layer 1 gives each PR a real environment to test against. Layer 2 verifies that environment against the behavior your code actually defines.

The One-Click Onboarding Flow

Getting started takes a single step: connect your repository to Autonoma.

Once the repo is connected, Autonoma reads your project structure, identifies your services, and maps the runtime topology. From that point on, every PR that opens triggers automated per-PR orchestration. Autonoma builds the images, provisions the full-stack environment, and exposes a unique preview URL with correct routing for the PR. The entire preview environment provisioning flow is handled by the product. Your team never touches Kubernetes operators, writes custom controllers, or maintains teardown scripts.

There are no tech stack limitations. Whether your app is a Next.js monolith, a Django API with a Celery worker, or a Node microservice cluster backed by Postgres and Redis, Autonoma provisions it as isolated runtime infrastructure per PR. The same onboarding flow applies.

Layer 1: What Gets Provisioned Per PR

Layer 1 is the managed preview infrastructure side of Autonoma. For every pull request, it runs the full ephemeral infrastructure lifecycle: build, replicate, route, expose, and eventually tear down.

Service replication means every service your app defines gets its own isolated container in the preview. Not a shared staging backend. Not a mocked API. The actual service, running the actual code from that branch. If your app has five services, the preview has five isolated containers wired together correctly.

Environment routing ensures the preview URL points to the right frontend, the frontend calls the right backend, and the backend connects to the PR's own database and cache. Routing is provisioned automatically and scoped to the PR. No manual BASE_URL substitution or environment config juggling required.

Secrets and config propagation means your environment variables, API keys, and service credentials arrive in the preview automatically. You define the source once during onboarding. Every subsequent per-PR environment receives the correct values without anyone copying credentials by hand.

Database isolation is per-PR. Each environment gets its own database instance, seeded from the baseline you configure. A migration in one PR cannot corrupt another PR's data. A test that inserts rows into the PR database does not pollute production or a shared staging schema.

Environment teardown is automatic. When the PR closes or merges, Autonoma tears down all containers, releases the routing, and removes the preview. The ephemeral infrastructure lifecycle has a clean end. No zombie previews accumulating costs, no dangling DNS records, no containers that someone needs to manually stop.

This is what the infra maintenance burden of self-built preview environments actually contains: every one of these operations requires either custom automation or manual intervention when you build the system yourself. Autonoma absorbs all of it.

Layer 2: The Three Agents

Layer 2 is the testing side. It runs on every preview Layer 1 creates, using three specialized agents.

The Planner agent reads your codebase: routes, components, API definitions, user flows. From that reading, it plans a set of test cases that reflect actual behavior your code defines. It also generates the database-state setup endpoints needed to put your DB in the right state before each test scenario. No one writes the test plan. No one records flows. The codebase is the spec, and the Planner derives the test coverage from it.

The Automator agent executes the planned test cases against the real preview URL Layer 1 provisioned. It runs against the actual frontend, the actual backend, the actual database. Not a mock, not a localhost. The full-stack preview environment is the test target. Each step has a verification layer, so the Automator does not take random paths through the app: it follows the plan the Planner generated, checks outcomes, and surfaces failures with context.

The Maintainer agent handles the ongoing reality that UIs shift. Selectors change, flows reorganize, new components appear. Normally, this is what makes E2E test suites expensive to own. The Maintainer reads the updated codebase after each change and heals tests that would otherwise break due to non-behavioral changes. Self-healing is not guessing: it derives the correction from the new code, not from retry logic. Zero maintenance burden is the design goal.

The three agents run hands-off. No one needs to click through the app, record flows, or write test scripts after the initial codebase connection.

Open Source

Autonoma is open source. The full codebase is available, and you can audit exactly how the agents work, how infrastructure is provisioned, and how the lifecycle is managed.

In practice, open source means two deployment options. Self-host if you need to keep everything inside your own infrastructure (common for companies with data residency requirements or strong cloud spend governance). Use managed if you want the product without operating the infrastructure it runs on.

No vendor lock-in is a design principle we take seriously because we know what it feels like to be dependent on a closed platform for something as foundational as your preview infrastructure. If you outgrow Autonoma or want to migrate, the codebase goes with you.

Who Autonoma Is Built For

Autonoma was designed for fast-growing startups shipping multiple PRs per day. The product makes the most sense when three conditions are true together.

Your team ships fast. Multiple PRs per day means environment demand compounds quickly. A system that relies on a shared staging environment, manual QA passes, or build-your-own preview infrastructure starts slowing you down at this cadence.

Your stack is full-stack. Frontend-only preview deployments give you a URL to click. They do not give you an isolated backend, an isolated database, or isolated queue workers. If your bugs live at the boundary between services (and most production bugs do), you need full-stack isolation per PR.

Testing is a bottleneck or a gap. Either your team spends time maintaining E2E tests that break on every UI change, or your team does not have E2E coverage at all because the setup cost was too high. The three-agent system in Layer 2 is built for both situations.

How Autonoma Operates the Full Per-PR Lifecycle End to End

The build-vs-buy decision for preview environments has two cost centers that are often counted separately but land on the same team. Upfront build cost runs 15 to 35 engineer-weeks for a complete setup covering image builds, service replication, per-PR routing, secrets propagation, database isolation, and teardown automation. Steady-state maintenance runs 0.3 to 0.5 FTE: the controllers drift, the DB isolation breaks on schema changes, the teardown scripts miss edge cases, the secrets rotation hits the wrong environment. Most teams that build this themselves undercount the steady-state cost until they're six months in.

Autonoma absorbs both cost centers as a managed product. Layer 1 handles the full per-PR orchestration: image build, full-stack service replication, environment routing, secrets and config propagation, database isolation, and environment teardown. Layer 2 handles the verification layer that build-your-own infrastructure leaves entirely uncovered. The result is that every PR gets a real environment and tested behavior with no infra overhead on your team and no testing gap after provisioning. The steady-state burden shifts from your platform team to Autonoma's managed infrastructure.

For teams already shipping at volume, this matters because preview environment provisioning at scale generates hundreds of environments per sprint. Managing that lifecycle manually, or maintaining the automation that manages it, is a platform engineering distraction that compounds over time.

How It Compares to Building In-House

Dimension	Autonoma	Build your own	Render / Railway Review Apps	DB branching only (Neon, PlanetScale)
Upfront cost	Connection + config	15-35 engineer-weeks	Low (Docker-native only)	Low (DB layer only)
Steady-state maintenance	Managed (zero FTE)	0.3-0.5 FTE	Low (runtime boundary)	Team owns orchestration
Full-stack isolation	Yes (all services)	Yes (if you build it)	Runtime only	DB layer only
E2E testing layer	Built in (Layer 2)	Not included	Not included	Not included
Tech stack limitations	None	None (you build it)	Docker-native required	Supported DBs only
Open source	Yes	Yours to own	No	Partially

The column that matters most for fast teams is steady-state maintenance. Build-your-own preview infrastructure does not stay built: it drifts, breaks on dependency updates, and needs ongoing attention. Autonoma's managed preview infrastructure absorbs that drift as part of the product.

For teams evaluating Render or Railway Review Apps, the gap is the testing layer and full-stack depth. Both stop at the runtime boundary and leave orchestration, secrets propagation, and environment teardown to your platform team. For teams evaluating database branching services like Neon or PlanetScale, those solve one isolation layer well and leave everything else (routing, secrets, service replication, teardown) as open problems.

The managed preview environments alternative we document in the build-vs-buy breakdown works through each category in more detail.

How to Start

The fastest path is a live walkthrough on your actual repository. Our co-founder Eugenio runs these weekly with engineering teams, walks through the onboarding flow, and shows you what Layer 1 provisions and what Layer 2 tests on a real codebase.

You come with your repo. You leave with a working setup or a clear answer on whether Autonoma fits your stack.

Frequently Asked Questions