When we launched Platform.sh, we wanted to make our user permissions model extremely flexible and granular by allowing you to grant your contributors different permissions for every single environment within your projects.
However, after analyzing the data and listening to your feedback, it became clear that this flexibility can be confusing and lead to unexpected behaviors. Also, it can be hard to manage or audit, when the number of projects and contributors that you own grows. This is because it requires you to update many environments in order to update user permissions.
This is why we’re excited to introduce Environment Types.
Environment types offer a simple way to group your environments together (Production, Staging or Development) and to set user permissions on those types at the project level.
In the future, we’ll introduce additional environment types and features that will simplify user permissions even more.
With Environment Types:
Note that our flexible branching model remains exactly the same. You can always deploy code from any environment to production directly without having to follow a constrained pattern (Development > Staging > Production).
Environment Types will be rolled out to all projects in the coming weeks. There’s no action required on your end to get access to this feature.
During the migration, an environment type will be assigned to every existing environment as follows:
Environment types only impact user permissions. After the migration, the user permissions defined on your Production and Staging environments will remain unchanged.
However, permissions defined on your Development environments will be the union of the permissions of all development environments. Some of your contributors might gain access to additional development environments. If you want to restrict access to some development environments, you simply need to change their types to Staging and set up permissions accordingly.