Code against the environment you need

A sneak peek at where we're taking autodev preview deployments: compose any set of services into one environment, and source each one exactly how you need it — a hermetic sandbox, a shared long-lived environment, or somewhere in between. It's arriving incrementally: today every preview runs the hermetic-sandbox configuration, and the composition and source-switching below are the near-term roadmap.

The problem with preview environments#

autodev, Miriel's AI-first, AI-enabled CI/CD ecosystem, makes it easy to stand up fully functional test deployments for you and your AI agents to code against: code gets pushed, images are built, and autodev brings up a working preview at a live URL. But every preview deployment forces a quiet compromise, and you've probably felt both sides of it.

Make it fully isolated — every service built from your branch, its own throwaway database — and it's fast, safe, and hermetic. But it's also a little bit of a fiction. It never talks to the real neighbors your code will actually run beside, so a whole class of integration bugs sails straight through.

Make it realistic instead — wire your change into live, shared infrastructure — and you catch those bugs, but now you're standing up (and paying for, and waiting on) the entire world just to test one service. And you're one bad write away from stepping on a teammate.

The honest answer is that there's no single right configuration. The right one depends on the change, and it differs service by service within the same test. So we stopped trying to pick one.

Environments: one deploy unit, composed from whatever you need#

The first half of the answer is a new unit we call an Environment.

Today a preview is single-repo by construction — one branch, one repo, one isolated stack, reachable only through public URLs. An Environment lifts that ceiling. It's a named, composed stack that pulls together a set of Services — from as many repos as you like — onto one shared network, where they discover and talk to each other by stable internal names, exactly the way they will in production.

A Service is just a deployable unit: a repo, or one service out of a monorepo (an api, a web frontend, a worker). An Environment is the comprehensive deploy unit you assemble those Services into. Your ordinary branch preview doesn't go away — it's simply the smallest Environment there is, one Service running on its own. Scaling up to a multi-service integration stack is the same object, wider.

flowchart TB
    Preview["Public preview URL"] --> web

    subgraph env["One Environment · one shared network"]
        direction LR
        web["Service: web frontend"]
        api["Service: api"]
        worker["Service: worker"]
        web -->|"finds by name"| api
        api -->|"finds by name"| worker
    end

That composition is what unlocks the interesting part: once several Services live together in one Environment, you get to decide, per Service, where each one comes from.

Flexible sourcing: dial in each service independently#

This is the half we're most excited about — the source axis.

For every Service in an Environment, you choose how it's sourced, and the choices are independent:

• Sandbox — built fresh from your branch. Isolated, disposable, seeded with its own data. This is the hermetic configuration: nothing you do can affect anyone else, and nothing anyone else does affects you.
• A shared environment — don't rebuild it at all; point at a long-lived one your team already keeps running (a dev or staging environment, say). When a Service isn't the thing you're changing, you rarely want to spin up your own copy — you just want a real one to talk to.
• Beyond that, a Service can bind to an external upstream you name, so an Environment can reach a system that lives outside autodev entirely.

Each Service in the Environment picks its own source, independently — so a single stack can mix a couple of Services built fresh from your branch with others that just point at what's already running:

flowchart LR
    subgraph env["Your Environment"]
        direction TB
        api["api"]
        web["web frontend"]
        billing["billing"]
        search["search"]
    end

    api -->|sandbox| S1["built fresh<br/>from your branch"]
    web -->|sandbox| S2["built fresh<br/>from your branch"]
    billing -->|"shared env"| S3["a long-lived<br/>shared environment"]
    search -->|external| S4["an upstream<br/>you name"]

Because the choices compose, the same three real-world workflows fall out naturally:

1. Complete sandbox. Every Service from your branch, private network, throwaway data. Fast and hermetic — does my change work at all?
2. One service, real neighbors. The Service you're changing runs from your branch; everything it depends on points at a shared environment. You get integration realism without standing up the world — does my change work against real neighbors?
3. Mixed. Some Services from your branch, some from a shared environment, a dependency from an external source. The exact stack a given change needs, and nothing more.

You're no longer choosing one environment and living with its compromise. You're dialing in the configuration per Service, per branch.

What your code needs to do#

All this flexible wiring needs one small thing from your services, and it's a good habit regardless: a service should read the addresses of its dependencies from configuration — environment variables autodev injects — rather than hardcoding a hostname into the image.

Get that right and one image runs unchanged no matter where a dependency actually lives. Your code just reads BILLING_URL and connects; whether that value points at a sibling container in the same sandbox, a shared long-lived environment, or an external system is autodev's problem, not yours. That's the whole ask — no service registry, no lookup machinery, just configuration — and most well-behaved services already work this way.

Where this is going#

The zero-config branch preview is live today, and it's the bedrock: push, and your change is running somewhere real that an agent can drive. Composing multiple Services into one Environment, and flipping each Service's source between a fresh sandbox and a shared environment, is what we're building on top of it now — additively, so nothing about today's previews has to change for it to arrive.

The goal is a preview deployment that stops being a fixed, take-it-or-leave-it box and becomes something you shape — the exact slice of your system a change needs, sourced exactly how you need it. Code against the environment you need, not the one your tooling happened to give you.

Want to see it in motion? Get in touch — we'd love to show you.