Lagoon currently differentiates between two different environment types:
When setting up your project via the Lagoon GraphQL API, you can define a
productionEnvironment. On every deployment Lagoon executes, it checks if the current environment name matches what is defined in
productionEnvironment. If it does, Lagoon will mark this environment as the
production environment. This happens in two locations:
- Within the GraphQL API itself.
- As an environment variable named
LAGOON_ENVIRONMENT_TYPEin every container.
But that's it. Lagoon itself handles
production environments in exactly the same way (in the end we want as few differences of the environments as possible - that's the beauty of Lagoon).
There are a couple of things that will use this information:
- By default,
developmentenvironments are idled after 4 hours with no hits (don't worry, they wake up automatically). It is also possible for your Lagoon administrator to disable auto-idling on a per-environment basis, just ask!
- Our default Drupal
settings.phpfiles load additional settings files for
production.settings.phpso you can define settings and configurations different per environment type.
- If you try to delete an environment that is defined as the production environment (either via webhooks or REST), Lagoon will politely refuse to delete the production environment, as it tries to prevent you from making a mistake. In order to delete a production environment, you can either change the
productionEnvironmentin the API or use the secret
forceDeleteProductionEnvironment: truePOST payload for the REST API.
- The Lagoon administrator might use the production environment information for some additional things. For example, at amazee.io we're calculating only the hits of the production environments to calculate the price of the hosting.