The frontend artifact is easy to underestimate.
Build the application. Put the assets somewhere reachable. Send traffic to the right origin.
That description ends before the user experience begins. A real frontend runs through a hosting platform, an edge cache, one or more proxies, server-side rendering, middleware, configuration injection, and the rules that govern a connection after the first response. Those parts decide whether the page feels fast, whether a stream survives, and whether staging is useful evidence for production.
Once those decisions differ by environment, deployment has become part of the application's runtime behavior.
The bundle is only one part of the runtime
Two environments can serve the same commit and still present different products to the user. One may hit a warm server-rendering process through a short proxy path. Another may pay a cold start, traverse a different route, miss an asset cache, or execute a different middleware chain. The React tree has not changed. The path that turns a request into a page has.
This distinction is easy to ignore when the frontend is mostly static. It becomes visible when a page needs server-side work, authenticated routes, rewrites, rate limits, or a backend connection that stays open longer than an ordinary request. Every one of those needs inherits the constraints of the runtime that carries it.
Treating the deploy target as packaging creates a blind spot. Teams compare build output while users experience request behavior. The right unit of comparison is the full path from navigation to rendered page, including the runtime work after the browser asks for it.
Page speed can change the hosting decision
Production page speed is a product concern. A slow first render makes a chart, search result, or account screen feel unreliable before any domain logic has had a chance to fail.
The usual response begins with code: reduce the bundle, optimize an image, cache a query, or remove a client-side waterfall. Those changes matter. They do not eliminate runtime cost. The host determines where server rendering runs, how long a process remains warm, where the cache lives, how requests queue, and how many proxy hops sit between the browser and the application.
That pressure can force a deployment change. In this case, a managed frontend path remained useful for development and staging, while production moved to a container runtime because the production performance profile needed different control. The container runtime fit the production request path more closely.
Deployment decisions deserve product attention. A latency budget does not stop at application code. If the runtime cannot meet it reliably, the architecture has already made a product decision on the team's behalf.
Streaming makes the boundary visible
Streaming is where hosting assumptions stop hiding.
A normal request has a beginning, a response, and a short lifetime. A stream asks the platform to keep state alive while data is produced elsewhere, flows through proxies, and reaches a browser that may remain connected for minutes or hours. The platform must preserve the response instead of buffering it, keep the connection within its timeout rules, and let the application observe a disconnect soon enough to clean up useful state.
Those conditions involve more than the frontend process. They include the browser-facing route, load balancers, reverse proxies, CDN behavior, server runtime, and the upstream service that publishes the events. A stream that works against a local development server proves very little about that chain.
An intermediary function can bridge a gap. In this deployment, a Lambda-based workaround kept a long-lived stream available through the older frontend path. That was a reasonable way to preserve product behavior while the architecture changed. It was also evidence that the stream's lifecycle and the host's request model were poorly matched.
Workarounds are useful when they make a boundary explicit. They become risky when the team starts treating them as a property of the product. A function with its own timeout, buffering rules, authentication path, and failure surface creates another runtime contract to operate. The user only sees whether updates arrive, pause, or disappear.
Streaming forces a clearer question: which layer owns the connection from the browser to the service that is producing live state? If that answer requires a chain of exceptions, the deployment boundary needs attention.
Environment drift creates a second product
Moving production to a different runtime does not make the old environments worthless. It changes what they can prove.
Development and staging may still provide fast feedback, isolated previews, and a convenient place to exercise most application behavior. Production may now have a different container image, startup path, proxy route, cache policy, runtime configuration source, and promotion trigger. Each difference can be intentional. Leaving it unnamed turns it into a future debugging exercise.
The dangerous version of drift is familiar. A page is fast in staging and slow in production. A stream connects locally and closes behind the production proxy. A preview uses the correct public origin while the promoted image carries an older value. An authentication callback works on one host because its route rules happen to be different there.
These are deployment bugs with application-level symptoms. The code review can look clean because the application source did not change. The behavior changed through the environment that executed it.
Parity does not require identical infrastructure. It requires an honest model of the differences and a validation path for the behavior that each one can change. If production is intentionally different, production checks need to cover the capabilities that motivated the difference: page delivery, server rendering, streaming, configuration, and promotion.
Configuration has a runtime boundary too
Frontend configuration is often handled as an implementation detail. Build variables are convenient until a value needs to change after an image exists, or until the same image must run in more than one environment.
The browser can only read values that are safe to expose. That boundary should be an allowlist. An allowlist expresses the boundary more clearly than a naming convention that developers are expected to remember. A runtime configuration script can publish the public origins, feature switches, and client identifiers that the browser needs. It should not be a second environment file with every available setting copied into it.
The distinction matters for both safety and promotion. Secrets placed in a client bundle or image layer remain available after the build system has finished with them. Replacing a build-time secret with runtime injection does not solve the problem if the browser can still retrieve the result. Server-only credentials need to remain on the server side of the boundary.
An allowlisted runtime configuration path also keeps public values honest. The same promoted image can receive the public URL and service endpoints intended for its environment, while the image remains free of configuration that should never have been included. That makes a configuration change visible as runtime behavior instead of burying it in an old artifact.
Promotion is a behavior change
Deployment pipelines often describe promotion as movement: a commit becomes an image, an image becomes a task, and a task receives traffic. The user sees a different sequence. They receive a page through a specific route, with a specific configuration, cache state, connection policy, and backend reachability.
Those conditions are part of the release.
The result is a clearer frontend deployment contract. The release must state which runtime serves production, which public values are injected there, what keeps a stream alive, and which environments can validate the same path. It also needs an answer for the failure cases: how a bad image is rolled back, how a stale configuration is detected, and what the UI does when a live connection ends.
That contract is more useful than a platform preference. A managed host can be a good fit. A container service can be a good fit. The decision should follow the behavior the product requires and the failures the team is prepared to operate.
The one-line version
Frontend deployment becomes runtime architecture when the environment decides how quickly the app loads, whether it can stream, and how it fails in front of users.