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_TYPE in 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:
development environments 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.php files load additional settings files for
production.settings.php so 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
productionEnvironment in the API or use the secret
forceDeleteProductionEnvironment: true POST 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.