Why a VPN does not make your dev preview safe to share

Putting a prototype behind a VPN feels private, so the only remaining question looks like who gets the profile. That assumption fails in a specific way: a tunnel controls who can reach a host, not what the host exposes once they arrive. The preview still runs a runtime, holds data, and calls integrations that can send real email or write to a real database. Treat the VPN as the front door and then design the room behind it.

A route is not an audience

Enrolling a tester in the VPN answers exactly one question: can this device reach the address. It says nothing about which pages, APIs, or consoles that device may use. Those are separate permissions, and a gateway that only knows about addresses cannot enforce them.

Write the preview contract as a short list: hostname, listener, allowed operations, and who holds each role. Then check that the list matches what is actually exposed.

A tester who can open the prototype does not need the deployment console, the database admin page, or the developer's home directory. If the gateway grants a subnet route, every one of those is reachable by default. Prefer a per-destination route, or put the extra services behind their own authentication. Either choice narrows what a stolen profile can do.

The runtime you share is part of the contract

A development server with a debugger and auto-reload is a tool for one person on one machine. Framework documentation is blunt about this: Flask's deployment guide says its development server and debugger are not for production, and it counts private or single-user services as production too. The same reasoning applies to any framework with a reloader and an interactive error page. Convenience features are designed to shorten the loop between saving a file and seeing a change, not to face a tester you do not control.

An interactive traceback is an information leak and, in some debuggers, a code execution surface. Keep it off the preview, or restrict the preview to a build that cannot enable it. If testers need diagnostics, give them logs rather than a console.

A wildcard listener is the other half of this mistake. Binding to every interface exposes the service on networks you did not intend, including the coffee shop Wi-Fi.

Use throwaway accounts and data with no real side effects

Use accounts created for testing and data that cannot embarrass anyone. The dangerous part is rarely the database row; it is the integration behind the button. Email, payments, SMS, webhooks, and file exports all reach outside the preview.

List every outbound effect the prototype can trigger, then point each one at a sandbox or disable it. A private route does not make a live payment endpoint harmless.

Production credentials are the same problem in a different shape. A preview that inherits the production API key to save setup time is a production system with a debug UI. Create scoped credentials with the smallest useful permissions. Rotate them when the preview ends, because a revoked preview with live keys is still live.

Check the page, the assets, and the socket

A page that renders is not a preview that works. The HTML may load while an asset host, an API, or a WebSocket still points at a URL the tester cannot reach. Each of those is a separate entry in the contract.

From an approved device, request the page and the largest asset separately:

curl -sS -o /dev/null -w "%{http_code}" https://preview.staging.example/
curl -sS -o /dev/null -w "%{http_code}" https://preview.staging.example/assets/app.js

Then watch the browser console during a real interaction and confirm the live-reload socket connects. If it does not, the fix is a deliberate route for that endpoint, not a rule that widens until the page looks complete.

Retire the preview on a date, not on memory

Give the preview an owner and an end date at the moment you create it. When the date arrives, remove the entry, the tester identities, and the temporary credentials through whatever configuration owns them. A forgotten preview is how a private prototype becomes a permanent public one.

Verify the retirement from outside: the hostname should stop resolving or stop answering for unapproved clients.

Keep the source and the recovery notes, but not the fallback. The test of a good preview boundary is boring: an approved device can do the required actions, and an unapproved identity cannot. The same must hold after the tunnel is switched off. That result is worth more than a VPN icon next to a prototype running with every development feature enabled.