• Overview
    Key features
    • Observability
    • Auto-scaling
    • Multiframework
    • Security
    Frameworks
    • Django
    • Next.js
    • Drupal
    • WordPress
    • Symfony
    • Magento
    • See all frameworks
    Languages
    • PHP
    • Python
    • Node.js
    • Ruby
    • Java
    • Go
  • Industries
    • Consumer Goods
    • Media/Entertainment
    • Higher Education
    • Government
    • Ecommerce
  • Pricing
  • Featured articles
    • Switching to Platform.sh can help IT/DevOps organizations drive 219% ROI
    • Organizations, the ultimate way to manage your users and projects
  • Support
  • Docs
  • Login
  • Request a demo
  • Free Trial
Meet Upsun. The new, self-service, fully managed PaaS, powered by Platform.sh.Try it now

How to keep your development environments in sync with production

environments

Notes

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 feature-1 branch. 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 feature-1 branch. 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.

Build your greatest app

Get started
Company
AboutSecurity and complianceTrust CenterCareersPressContact us
Thank you for subscribing!
  •  
Field required
Leader Winter 2023
System StatusPrivacyTerms of ServiceImpressumWCAG ComplianceAcceptable Use PolicyManage your cookie preferencesReport a security issue
© 2024 Platform.sh. All rights reserved.
Supported by Horizon 2020's SME Instrument - European Commission 🇪🇺