How to Speed Up Your Release Cycle with Environment Permissions and PoLP

Why the release cycle keeps getting stuck

In our company, we have ten apps in production that we update every month. The role of “release developer”, or “release engineer” is rotated within our team for every release.

To comply with the principle of least privilege (PoLP), we only want to give deployment permissions to the release developer when they need them. So, before every release, we need to be able to grant the right person access to deploy to production and revoke their access after the release.

Assigning project roles in Mendix

In Mendix you can give developers access to your project by assigning them a specific role.  As of January 2025, we’ve made a few updates:

• Only company admins can define roles.
• Roles can now include public cloud environment permissions.
• You can also use the Project API to assign a team member to a project with a specific role.

For this release cycle example, we’ll need to set up two roles: one for a regular developer and another for a release developer who will have permission to deploy to production.

Creating a regular developer role

Let’s start by creating a normal developer role. In the Control Center click on the People section of the menu and open the Roles & Permissions section.

1 – Edit the Project Role Details section

Since there is already a regular Developer role to choose from, we‘re going to start by editing that role. The first step will be describing what permissions this role will have (see screenshot below for example).

2 – Edit Project Permissions

When you’re through with your description, click Next to set the project permissions for this developer role. Here are some thoughts to consider:

• Project Admin permission: We recommend assigning this permission only to the (system) Scrum Master role. It allows the user to manage team member permissions and change project settings—powerful actions that should be tightly controlled.
• Team Server permission: This permission gives access to the team server so developers can commit their work. It’s essential for any developer role.
• Planning and Feedback: Developers will need this permission to view and work on the user stories assigned to them.
• Invite Members: We suggest limiting this permission to the (system) Scrum Master role. It allows users to invite new members to the project and assign them roles, so it’s best kept to a minimum.

3 – Set the Non-Production Environment permissions

Access Rights

Start by choosing whether this role should have any access to non-production environments.

• For developer roles, some level of access is required.
• For other roles, you can set this to No Access, which means the user won’t receive any permissions on non-production environments—and you can skip the rest of this section for that role.

Permissions Management: Fixed vs Custom

This setting controls how non-production environment permissions are applied and managed.

Fixed

When a role uses Fixed permissions, the permissions listed in the role definition are enforced automatically. Users assigned this role will receive the exact permissions defined here, and people in the project with Manage Cloud Permissions will not be able to manually change permissions from members that have this role.

In short, this means that a company admin can be sure that a member with this role in a project has exactly the permissions listed here.

Custom

With Custom permissions, the role itself does not determine access. Permissions must be manually assigned in the Mendix Developer Portal by someone with the appropriate rights or set via API.

Important: If a user already has permissions (e.g. as a Scrum Master), assigning a role with Custom permissions won’t automatically revoke them. Those existing permissions will remain until they’re changed manually or through an API.

We recommend using Fixed permissions whenever possible, because it gives you total central control and avoids unexpected permission gaps. Use Custom permissions only if you must make a distinction between different non-production environments such as allowing deployments to Development and Test, but not Acceptance.

In the case of our developer role, we’ll grant the developer full permissions on non-production environments apart from the ability to manage permissions themselves.

4 – Set the Production Environments permissions

In this last step of the editing the project role, we’ll configure the production environment permissions. Since any changes to production require two-factor authentication, the company admin will need to authenticate the account before proceeding.

Once authenticated, we can set the appropriate permissions. Developers should be able to monitor what’s happening with their app in production, so it’s a good idea to grant monitoring access.

With that, the regular developer role is set up. Now when a developer is assigned this role in a project, they’ll immediately be able to deploy to non-production environments and view monitoring information in production – something that used to require manual configuration by a Scrum Master or technical contact. A big productivity win!

Creating the Release Developer Role

Next, we’ll define the release developer role—used specifically for deploying to production.

To encourage this role’s use only when needed (and ensure it’s revoked after deployment), we’ll keep it extremely limited. This means the team member with this role will need to get their regular developer role back to continue their normal work.

That means..

• No project permissions
• No access to non-production environments

…and only the following production environment permissions:

• Deployment – to release to production
• Backups – to create a backup before deploying
• Monitoring – to confirm everything went smoothly

How to apply these roles

There are several ways a developer can be assigned a role in a project:

• A Scrum Master can add/invite a developer with a role.
• A company admin can add/invite a developer with a role.
• The project’s API is used to add a developer to a project with a role.

If a single developer—like Gaby Gable—needs to release multiple apps, a company admin can follow these steps to assign the Release Developer role across the necessary projects:  In the Control Center, search for Gaby in the Members List:

Click her name to see a list of all the apps she’s involved in.

Click on an app name to open the App Details panel. Go to the Members page.

After clicking Manage Members, change Gaby’s role to Release Developer.

Repeat these steps for each app that needs to be released. Once her roles are updated, Gaby will have the correct permissions to deploy across all assigned apps.

After the releases are complete, the company admin can use the same process to revert Gaby back to her original roles—ensuring she returns to regular developer access without unnecessary production permissions.

Granting temporary permissions on a specific environment

Sometimes, you may need to give a team member temporary access to just one environment but not to all production or non-production environments. Roles with fixed permissions don’t support that level of granularity; they apply permissions across all environments in either the production or non-production category.

So, what if you have multiple production environments, such as Production and Production2, and you want to grant temporary access to just Production?

For this use case you can define a Developer Custom role. Same permissions as a regular developer, but the permissions for (non)production are not included in the project role, though they can be set manually or by API.

Here’s how to handle that:

Set both non-production and production permissions to Custom.

Let’s say Gaby currently has a role with fixed permissions. This means her environment access is locked and can’t be changed by the Scrum Master or technical contact.

You can view this in Mendix Portal of the app, in the Permissions tab of the Production environment – her permissions will appear as read-only.

To make Gaby’s permissions editable, assign her a different project role, in this case, Developer Custom.

This new role has the same project-level permissions as a regular developer. However, because its environment permissions are custom, they can now be updated manually by a team member with permission to manage environment access (such as a technical contact) or using the Deploy API.

This gives you the flexibility to grant temporary access to a single environment, without compromising control across all others.

Balancing Flexibility with Control

Custom roles give you the flexibility to handle exceptions—like granting temporary access to a single environment—without undermining your security model. Fixed roles, on the other hand, are ideal when you want to enforce consistent, centralized permissions across all projects and environments.

By combining both approaches thoughtfully, you support a key security best practice: the Principle of Least Privilege (PoLP). This means every team member gets only the access they need to do their job—no more, no less. Using fixed roles as the default and reserving custom roles for edge cases helps minimize risk while keeping your release process smooth and efficient.