what deployment infrastructure does a software factory need?

Repo-based execution is part of that answer. It is not the whole answer. A repository can tell an agent what should exist. The deployment substrate has to show the agent what actually happened.

In this article, a software factory means a system that continuously turns product signals into reviewed, running software. That is a working definition, not an attempt to settle the category. Factory describes the model as a move from individual coding assistance toward autonomous software development. The useful part of the metaphor is the loop: observe, change, run, verify, release, observe again.

That loop makes deployment infrastructure part of the factory itself.

start with a real change

Suppose a factory receives a support report and a trace showing that an import job times out on large files. An agent proposes a change across three parts of the system:

1. the API accepts the import and returns a job identifier;
2. a worker processes the file asynchronously;
3. a database migration records progress and retry state.

Producing the patch is only the first step. Before a human should approve it, the factory needs answers to harder questions. Did all three services build? Can the API reach the worker? Did the migration run against isolated state? Does the retry path work? What changed at the network boundary? If the release fails after production traffic moves, what can be reversed, and what cannot?

Those are deployment questions. A software factory that cannot answer them is a code generator with a merge button.

The 2025 DORA report reaches a related conclusion from a different direction: AI tends to amplify the quality of the system around it. Faster code production helps when feedback, platform quality, and delivery controls are sound. It creates more disorder when they are not. DORA's platform engineering research calls this failure mode downstream disorder.

For a software factory, the deployment platform is where that disorder either becomes evidence or becomes risk.

1. one reviewable source of truth

The factory needs a durable answer to: what are we trying to run?

Application code, service topology, build instructions, routes, access policy, and auditable configuration should live with the change that modifies them. A reviewer, whether human or machine, should be able to inspect one diff and understand the proposed system. The deployment platform should execute from that state, not maintain a second copy of it behind dashboard controls.

This is why the recent move toward repo-defined infrastructure matters. Vercel Services lets a repository describe multiple services in vercel.json, then gives those services a shared preview and rollback boundary. That closes an important gap between an agent editing a repo and a platform understanding the resulting application.

But repo-based does not mean repo-only. Secrets stay out of git. Runtime evidence does not belong in a manifest. The invariant is narrower: auditable desired state has one reviewable authority, while the platform owns execution and reports the observed result.

If an agent can change a route in one place while a dashboard quietly holds a conflicting route elsewhere, the factory has two truths. It will eventually deploy the wrong one.

2. a disposable, production-shaped environment

Static analysis can reject many bad changes. It cannot prove that several processes start together, credentials resolve, a migration applies, or a queue consumer receives work.

The factory therefore needs a running environment for the proposed change. It should be cheap enough to create for each meaningful branch and disposable enough to remove without ceremony.

“Production-shaped” needs a precise boundary. Here it means the preview has the same application service, routing, and access shape, plus isolated managed state where the platform supports it. It does not mean production traffic, production scale, a copy of production data, every user-owned external dependency, or a byte-for-byte replica of production.

That distinction matters. A preview with a separate database can safely test the example migration. It cannot make a charge against a third-party payments account safe. The factory still has to replace, sandbox, or explicitly gate external side effects.

The environment also needs provenance. The factory should be able to connect a commit to a deploy, a deploy to a URL, and the URL to the managed resources created for that preview. Otherwise, the agent is testing “something running somewhere,” not the proposed change.

3. feedback that machines can use

A software factory cannot operate through screenshots and spinner states.

It needs structured answers to basic questions:

• Did the deploy reach a terminal state?
• Which service failed?
• What URL should the verification step call?
• Which commit and configuration produced this runtime?
• Where are the build and runtime logs?
• Which managed resources belong to the preview?

Human-readable output still matters. Machine-readable output is the contract. Stable identifiers, explicit states, useful exit codes, JSON responses, and bounded waits let the factory act on evidence instead of parsing prose or guessing from elapsed time.

The deployment platform does not verify the application on the factory's behalf. The factory owns the checks that matter to its product: exercise the import endpoint, watch the worker, query the progress record, test a retry. The platform's job is to provide a faithful environment and enough structured runtime information for those checks to run.

This is also where an agent needs a clear failure surface. “Deploy failed” is not enough. A useful response identifies whether the failure came from configuration, a build, a health check, routing, or application startup, then points to the next piece of evidence.

4. a human boundary based on consequence

Putting a person in every loop turns the factory into a ticket queue. Removing people from every loop turns it into an unbounded production actor.

The useful boundary is consequence-based.

A factory can usually let an agent read logs, create an isolated preview, run tests, and replace that preview without approval. It should stop when the next action can affect customers, shared state, money, credentials, public access, or an irreversible external system.

Vercel Agent is a good current example of this direction. It uses its own identity, starts read-only, works in a sandbox, and moves from a plan to requested permission with human approval. The point is not that there is one universal approval model. The point is that authority should expand at an explicit boundary, not leak out of a broad credential.

For deployment infrastructure, the cleanest human boundary sits on the reviewed apply path. floo classifies proposed infrastructure changes before they apply. Additive work proceeds without approval. Teams can decide whether recoverable changes require review in each environment. Data-loss operations are always gated. A human approves the exact plan, not a broad credential. This keeps routine agent work moving while making consequential transitions explicit.

In the example, the factory can build the worker and run the migration in isolated preview state. Promotion to production, and any destructive follow-up after the schema transition, can remain distinct decisions with distinct evidence.

5. bounded reversibility and cleanup

“Can we roll it back?” is really three questions:

1. Can we route application traffic back to a known deploy?
2. Can we remove the temporary environment and its isolated resources?
3. What is the recovery path for data and external side effects?

These answers are not interchangeable. Moving traffic to a previous image does not undo a destructive migration, restore a deleted record, or reverse an email already sent. A responsible factory tracks code reversibility, state recovery, and external compensation separately.

The deployment platform should make the first two cheap and observable. The application and factory still need an explicit plan for the third. For the import example, that might mean a backward-compatible schema change, a repair command, and a retry ledger rather than assuming a code rollback restores the old world.

Cleanup belongs in the same contract. Preview resources need owners, expiry, and idempotent teardown. A factory that creates environments faster than it can account for them eventually produces cost leaks, stale credentials, and ambiguous test results.

the category is converging on the loop

Several platforms now expose agent-facing deployment surfaces. Railway documents a CLI, MCP server, and agent skills. Vercel has combined repo-defined multi-service applications with an agent that has identity, sandboxing, and permission escalation. These are meaningful improvements.

They also clarify the real evaluation question. It is no longer just “can an agent deploy?” Almost any sufficiently broad token can make that true. The harder question is:

Can the factory form a closed, auditable control loop around a real application without giving up isolation, legibility, or human judgment?

That requires the five properties together. A repo model without a production-shaped preview leaves verification thin. A preview without structured output leaves the agent half-blind. An agent tool without an authority boundary makes the happy path easy by making the failure path dangerous. Rollback without a state model creates false confidence.

a practical evaluation checklist

Before choosing infrastructure for a software factory, give it one change that crosses a web service, a worker, and managed state. Then ask:

1. Authority: Can the factory express the auditable system change in one reviewable diff?
2. Isolation: Can it create a branch-scoped running environment without touching development or production state?
3. Parity: Does that environment preserve the service, routing, access, and supported managed-state shape needed for the test?
4. Observability: Can a machine obtain deploy state, URLs, identifiers, diagnostics, and logs without scraping a UI?
5. Verification: Can the factory run its own checks against the resulting system and tie the evidence back to the exact change?
6. Authority boundary: Can routine preview work proceed automatically while consequential apply and destructive state actions remain explicit?
7. Recovery: Are traffic rollback, preview cleanup, and state recovery treated as separate contracts?
8. Cleanup: Can the factory enumerate what it created, who owns it, and when it expires?

Run the evaluation through the failure path, not just the demo path. Break a build. Fail a health check. Make the migration incompatible. Attempt a destructive action. The quality of the returned evidence tells you more than the number of integrations on the product page.

where floo fits

floo is built around this control loop.

The repository is the authority for the application and its auditable configuration. A branch can become an isolated preview environment with its own URL. When the application uses floo-managed Postgres, the preview can receive a preview-owned database branch while development and production remain untouched. That is enough isolation to test the example migration without pretending the preview contains production data or every external system.

The agent-facing surface is explicit. floo preflight validates configuration and reports the service and managed-resource plan before code reaches the platform. Deploy state, preview provenance, URLs, and logs are available as structured JSON. The factory still decides what correct behavior means, but it does not have to guess what the platform did.

The recovery boundaries are similarly narrow. A rollback moves traffic to an earlier deploy. It does not claim to reverse state.

Managed-service removal follows the reviewed config path. Remove the service's [managed.*] declaration from floo.app.toml in a pull request. floo classifies that diff as a high-impact data-loss operation and posts an infrastructure approval check. An org admin reviews the exact change, then the approved pull request can merge. Its approval carries into deployment. If an unapproved change still reaches main, the deploy-time gate pauses it as a backstop.

Teams can also configure whether recoverable changes require review by app and environment. Additive changes remain ungated. Agents keep moving below the boundary, while every data-loss action still requires a human decision.

None of this removes the need for good specifications, product-specific verification, or human judgment. It gives those parts of the factory a substrate they can reason about.

Once the requirements are written down, floo becomes an unusually strong default for teams building a software factory: git holds intent, previews make changes real, structured interfaces return evidence, and consequential state transitions stay visible. If the factory is how software gets made, the cloud beneath it is part of the machinery. floo is designed around that machinery from the start.