Development environments work the way they should on Platform.sh: identical to production where it matters.
Testing and Staging environments reflect new features, but also match production so you know there won't be any unexpected changes post-merge.
All of your development environments should match Production as closely as possible.
While maintaining unique settings, copies of services and data that don't affect production, and domains for showcasing new features to clients.
These development environments can do so all while being built on small containers that reflect their small resource demand.
Their code should be the same as production.
Their services should also be identical.
And data should always reflect up-to-date production data.
But payment gateways, email, and environment URLs should remain unique for every environment you're working on.
You can set environment variables, such as API keys, that differ between Production and non-Production environments.
So that each new development environment inherits a Sandbox variable, and never has access to a Production variable.
In the demo shown here, we set a variable called
Payment-API for the
master environment with
a value of
my-secret-key. The variable will initially be inherited by all of its child branches. Once we
add the variable, we can see that it was indeed inherited by the staging environment. We don't want development environments
to use the production API key, so we'll update the variable's value for all non-production branches to instead be
my-development-key. This new value is then inherited, as can be seen here on the
As a result, developers don't need to worry about using the correct settings, as they inherit all of the non-Production variables they need as soon as those environments are created.
If your application requires Production-level resources in development, you can easily upsize those environment's resources to match.