Separate production and staging with environments
See how environments separate application networks and data, and where that separation ends.
A developer runs a test script against staging, and a few minutes later real customers receive a test email, because staging had been writing into production all along. Keeping the two apart should not depend on everyone copying the right variable.
Each project starts with production, and an additional environment, such as staging, groups its own applications, databases and variables. Its application network is separate from production, even when both run on the same cluster, so staging works with its own data from the start.
Scene 1 of 7: Servers in three places
These nodes run at Hetzner, DigitalOcean and home. They use public addresses here. Nodes on a shared private network can use private addresses instead.
One network per environment
An application joins its own environment's network and reaches the databases there by their runtime names. A staging application cannot connect directly to the production database through that network, and traffic between nodes crosses the encrypted cluster network.
The edge router joins the networks whose applications it serves. It does not forward packets between them, though it can reach each of them, so a compromised router or a container escape could cross this boundary. Code you do not trust belongs on separate servers.
Public addresses stay public
A staging application can still call production's public HTTPS address like any visitor, so authentication protects what network separation does not. Tenkai adds no per-port rules inside an environment network.
Copies have their own data
Create a database from a backup in another environment to inspect a copy without stopping production. The new database has its own credentials, and later production writes never reach it. A copy holds real customer data, so give access to it with the same care as production.