Staging configuration travels, and agents help it

The fastest way to get something working is to copy the configuration from wherever it already works. It is a reasonable technique and most of us have used it, and an agent asked to make a deployment work tends to reach for it for the same reason we do: it is the shortest path from broken to working, and nothing in the task says otherwise.

Configuration copied from staging is configuration that says staging — in a hostname inside a <link rel="canonical">, in an X-Robots-Tag header, in the origin an API is willing to answer. None of those is contradicted by anything running on your machine.

What actually travels

These are not hypothetical. They are the ordinary residue of an environment that was cloned rather than derived.

A canonical tag pointing at the staging hostname. The template renders <link rel="canonical" href="https://staging.example.com/pricing"> on the production page. Every browser renders the page normally. Search engines are told, by you, in your own markup, that the authoritative copy of this page lives at an address they cannot reach or should not index. The page is live, correct and quietly asking to be excluded.

A noindex that shipped. Staging carries X-Robots-Tag: noindex or a meta equivalent so it does not compete with the real site. Correct. Then it rides along in the image, the config map, or the nginx snippet somebody copied, and the production site is now instructing crawlers to drop it. The page renders perfectly. Traffic decays over weeks and the cause is a header nobody reads.

A test API key. Payments succeed in the test ledger and never charge anybody. Email sends to a sandbox that accepts everything and delivers nothing. The application logs success on every path, because from its point of view every path succeeded. This one is particularly cruel: it fails by working.

A database URL. Production pointed at the staging database, or worse, staging pointed at production and now writing to it. The first is a site whose data quietly does not persist where anyone expects. The second is a test suite mutating real rows.

A CORS origin. Access-Control-Allow-Origin: https://staging.example.com, served in production. The API answers every request from a browser at the real hostname with a response the browser then refuses to hand to the JavaScript that asked for it. The server's logs show 200s. The user sees an empty panel. The developer, testing from a tool that does not enforce the same-origin policy, gets a clean 200 and moves on.

A robots policy. Not just noindex — a robots.txt with Disallow: /, or a sitemap reference pointing at the staging host, or a crawl-delay written to stop a load test from hammering a small box.

Why none of these show up locally

Every item on that list is a fact about the response a stranger receives from a particular deployed hostname, not a fact about the code. The repository is identical in both environments. The difference is in what an environment variable, a config map or a build-time substitution put there, and by definition that substitution does not happen on the machine where the code was written.

So the local check cannot see it. The unit test cannot see it — it does not make an HTTP request to a public hostname. And whoever verified the change, human or agent, verified it against the dev server, where the canonical tag rendered a localhost URL and nobody minded.

And the browser will not tell you either. A canonical tag, a robots header and a CORS origin are all invisible in rendered output. You have to look at the headers and the markup as delivered, at that address, from outside.

Check the deployment, not the intention

The correction is to stop treating "it passed on my machine, and the deploy reported success" as evidence about production, and start observing production as its own object. Observation does not prevent any of this — the wrong header still ships — it changes how long the wrong header is live before somebody knows. For a canonical tag or a robots policy, that interval is the entire cost.

Three checks cover most of what travels. They do not cover all of it — the limit is at the end of this section, and it is a real one:

• http-headers reads the headers the deployed host actually returns — including X-Robots-Tag, cache directives and anything else that arrived in a copied config file. You assert what should be there; the check tells you what is.
• robots-policy fetches robots.txt and the meta and header equivalents, and tells you whether this hostname is currently asking to be indexed or asking to be forgotten. Two environments should disagree about this, and only one of them should say Disallow: /.
• cors-policy makes the preflight request from an origin you name and reports what came back. This is the only way to see the failure, because the server does not consider the request an error and the browser's refusal happens after the response has already been logged as a 200.

None of these three detects a test API key. That is a real limit and worth stating: from outside, a payment that succeeds in the test ledger looks exactly like a payment that succeeded. Credential provenance is something only your own deployment process can assert, and the fix is that production secrets come from a store nothing else can read, not from a file that was copied.

Why an agent makes this worse, specifically

The difference between a person doing this and an agent doing it is not care. It is that a person who configured both environments by hand ends up knowing how the two differ, and that knowledge is what makes them stop over a pasted value whose origin they cannot name. The pause is a side effect of having done the work slowly, and it is doing more safety work than anyone credits it for.

An agent produces a configuration that is quick, plausible and mostly correct, and nobody ends up holding that map. Not the agent, whose context for the task ends with the task. And not the reviewer, who is reading a diff — where the value appears as a variable name — rather than the substitution that fills it at deploy time. There is nothing to be uneasy about, because nobody remembers making a decision.

Which is why the check has to be external and automatic. The environments no longer differ in ways anyone is tracking. They differ in ways only the deployed response can tell you about.

The cheapest moment is before DNS

There is a version of this that costs almost nothing. Run the checks against the staging URL — the real deployed staging host, not localhost — before you point production at it, or before you promote the image.

At that moment every value on the list above is observable at an address that exists, and none of them is affecting anybody yet. You are not looking for staging to be perfect; you are looking for the list of things that are true of staging and must not become true of production. That list is short and reading it takes a minute. The alternative is finding out from a search engine, and a page dropped from an index does not come back the moment you fix the header — it comes back on the crawler's schedule, which for a small site is measured in weeks.