A different URL does not guarantee that a test environment is separate from production. If its configuration still points to the real database, uses an active API key, or calls a production service, a test can change data or trigger actions outside the review environment.
Worker Previews, which Cloudflare launched in September, create environments for branches with their own code, configuration, URL, observability, and state. The idea makes it easier to review a change before deployment. Isolation, however, depends on the resources each preview receives and on limits the platform still has.
Check where each resource points
A preview starts with a base configuration that the team defines separately from production. Variables, secrets, and resource bindings can have their own values; teams can also override a preview's configuration to use a test database or API key, for example.
Durable Objects and Containers receive namespaces and applications isolated per preview. This prevents a branch's state from directly changing the instances used in production. For other resources, the team must check the configured binding: a different environment name does not automatically create copies of databases, buckets, or external APIs.
There are also limits between Workers. Today, a service binding called by a preview can still reach the bound Worker in production. Cloudflare says it is working to keep the entire request path within matching previews. Until that changes, a test that crosses this connection needs to account for the possibility of running code or producing effects in the real service.
Choose the environment based on test risk
A disposable preview works for checking a branch change when data and credentials can be separated or recreated. Persistent staging serves tests that need to retain state longer, but requires rules for cleanup, access, and maintenance. To test only a specific version of the code using production resources, Version URLs have a different purpose: they do not isolate resources and are not intended for branch or pull request review.
Before sharing the link, list the possible effects of a test: writes, message delivery, charges, emails, external calls, and migrations. For each one, decide whether the preview should use its own resource, a simulation, or a limited credential. Disable anything the review does not need.
Test the boundary, not just the page
Open the preview with a test account and inspect its logs and binding calls. Confirm that test data does not appear in the real environment and that sensitive actions are not triggered outside the branch. A correctly rendered interface does not show that the resources behind it are isolated too.
This check matters especially when a preview runs migrations or operations with persistent state. If a shared service is still in the path, use disposable data, a controlled copy, or limit the test to reads. Also record which settings are inherited from the base, so a new branch does not receive a production secret by mistake.
Worker Previews reduce the work of creating separate environments, but they do not remove the need to choose which resources and effects are allowed. The approval criteria for a preview should include where its data and calls go, as well as the address the team opens in a browser.
If your team is facing a similar decision, reach me on LinkedIn or WhatsApp.
