what infrastructure does a production application need?

A coding agent can produce an application repository in an afternoon. The repository is not the application users experience.

The running system also needs a place to execute, somewhere durable for important state, a route from users to the right process, configuration that survives replacement, and enough operational evidence to explain what happened when a change fails.

The useful question is not “Which infrastructure products should every application have?” It is:

What is the smallest system that preserves this application's state, execution, access, and failure semantics?

That answer often begins much smaller than a cloud architecture diagram suggests.

the smallest correct production stack

Consider a team building a document-review application with an agent. A user uploads a document, adds notes, and shares the result with a colleague.

The first production shape can be six things:

1. A web service receives HTTP requests and returns the interface and API responses.
2. Postgres stores users, document metadata, notes, permissions, and workflow status.
3. Object storage holds uploaded document bytes when files are large enough that database storage is no longer the right tradeoff.
4. Routing and access policy give the application a stable URL and decide who may reach it.
5. Configuration and secrets tell the service how to connect to state and external systems without embedding credentials in code.
6. Operations expose deploy state, logs, health, rollback, and the provenance connecting a running revision to a source change.

Even object storage may wait. A small application can keep modest files in Postgres while the team validates the product. The point is not to prohibit a layer. It is to require each layer to solve a named problem.

smallest correct stack

This is already a production architecture. It is small because the workload is small, not because production responsibilities disappeared.

compute: where code runs

Compute is the replaceable part of the system. It turns requests, messages, or schedules into work.

The three common roles are:

• A web service listens for requests.
• A worker continuously or repeatedly consumes work outside the user request.
• A cron job starts work on a schedule and exits.

Do not put all three into the diagram by default. Add a worker when document processing can outlive the request, needs retries, or should absorb bursts. Add cron when a task begins because of time, such as generating a weekly report or deleting expired exports.

Cloud Run's own guidance makes the request boundary concrete: with request-based billing, background activity after the response can lose CPU, and a timed-out request can continue processing even after the client receives a 504. The documentation recommends finishing asynchronous work before returning or choosing an execution model intended for background work.

The architecture lesson is broader than one platform. If completion matters after the response, give that work an owner outside the request.

The detailed choice belongs in web service vs worker vs cron job.

state: what must survive replacement

State should be classified by what happens if the current compute instance disappears.

• Business records usually need a durable database.
• Cached values may be recomputed or fetched again.
• Queued work needs explicit delivery and retry semantics.
• Uploaded files need storage designed for object payloads and access policy.
• Process memory and local disk are temporary unless the runtime explicitly promises otherwise.

PostgreSQL transactions bundle related changes into an all-or-nothing operation, and constraints can reject invalid records regardless of which application path attempted the write. PostgreSQL documents both transaction atomicity and database-enforced constraints.

That makes Postgres a strong starting point for records such as a document, its owner, and its workflow status. It does not mean every byte or coordination problem belongs there forever.

The state-specific decision framework lives in database vs cache vs queue vs object storage.

edge: how users reach the correct system

An application needs more than a container that starts.

The edge owns:

• a stable URL or domain;
• routing to the correct service and environment;
• TLS termination;
• access policy;
• health-aware traffic movement;
• separation between preview, development, and production routes.

These responsibilities become more important when agents produce several changes in parallel. A URL without environment and source provenance is ambiguous. An access rule that lives only in a dashboard can drift from the repository. A preview that shares production state can turn a route test into a data incident.

The edge is where a running revision becomes an application somebody can actually use.

environments: where a change becomes evidence

A local process proves that code can run on one machine. It does not prove that the application topology, routes, credentials, migrations, managed state, and access policy work together.

A useful preview environment gives one proposed change an isolated running system. It should preserve the relevant production topology while keeping development and production state outside the blast radius. That is the distinction developed in what is a production-shaped preview environment?.

For an agent, the preview closes a critical gap:

repository change → running system → machine-readable evidence

Without that loop, the agent can inspect code and test local behavior. It cannot reliably observe what the deployment substrate actually produced.

operations: how the system explains itself

Every production application needs a minimum operating contract:

• Which commit and configuration produced this deploy?
• Which environment and services does it belong to?
• Did each stage succeed, fail, pause, or get superseded?
• Where are service-scoped logs and diagnostics?
• Is retry safe?
• What does rollback change?
• Which state changes require a human decision?

This contract matters more as the cost of producing changes falls. Agents can generate more deployments, more migrations, and more parallel branches than a human team would create manually. Infrastructure must make those operations attributable and bounded.

The full agent-facing contract is described in what should deployment infrastructure return to a software agent?.

when the stack should expand

Return to the document-review application. Usage grows, and the team learns four things:

1. OCR can take several minutes and should not hold the upload request open.
2. Several users request the same expensive document summary.
3. Customers schedule recurring compliance reports.
4. Uploaded source files are much larger than the relational records that describe them.

Now the expanded stack has evidence behind it:

Each addition solves a measured problem and creates a new failure mode. That is the correct exchange.

common failures in agent-generated applications

Agents frequently optimize for code completion rather than runtime ownership. Watch for these shapes:

• user or workflow state stored in a module-level dictionary;
• files written to local container disk and assumed to survive replacement;
• email, OCR, or model calls completed before returning an HTTP response;
• cron used as a queue by polling for unfinished rows every minute;
• Redis added because it appears in a template, with no cache or coordination workload;
• queue consumers that can apply the same external side effect twice;
• preview services receiving development or production credentials;
• migrations tested only against an empty local database;
• a rollback described as if it reverses database state.

The fix is not a larger diagram. It is explicit ownership for state, execution, evidence, and recovery.

where floo fits

floo treats the application environment as one production model. Repository configuration describes services, routes, access policy, cron, preview posture, and supported managed attachments. GitHub events drive deployment. The CLI and dashboard inspect the same lifecycle instead of becoming alternative deployment authorities.

A small application can begin with a web service and floo-managed Postgres. As the workload earns more structure, the application can add workers, cron, Redis, and storage within the same environment model. Production-shaped previews give supported managed resources preview-owned identity and credentials rather than inheriting development or production state.

Agents receive deploy state, preview provenance, URLs, logs, diagnostics, and resource context through structured interfaces. Humans remain at launch, access, spend, and high-impact state boundaries.

That is the infrastructure a production application needs: not every possible primitive, but one legible system that can grow without changing who owns intent, runtime evidence, and consequential decisions.

Map one application using the smallest-correct-stack table. If the result needs a web service, durable state, isolated previews, and an operating loop an agent can use, request access to floo.