Every Platform.sh user has a role that controls their access and permission levels. Different roles allow different levels of access to your applications, environments and projects. You can manage how users interact with your project and environments at Platform.sh
Any user added to a project or an environment type on Platform.sh will need to register for an account before they can contribute. If you need to delete your account at any time you can transfer ownership of your existing projects and then open a support ticket to request your account deletion.
Grant user permissions to the entire project:
- Project Viewer - A project viewer can view all environments of the project.
- Project Administrator - A project administrator can change settings, push code and execute actions on all environments of the project.
You can also define user access per environment type (Production, Staging, Development). Each permission level progressively increases access to the environments part of a given environment type:
- Viewer - Viewer can view all environments of this type.
- Contributor - Contributor can push code and branch all environments of this type.
- Administrator - Administrator can change settings and execute actions on all environments of this type.
After you add or remove a user from a project or an environment type, you will need to trigger a redeploy to propagate the access changes to each environment.
You can redeploy by using the CLI command
platform redeploy or the
Redeploy button in the management console.
If you want your contributors to be able to see everything, but only commit to environments of a certain type, set their permission as Project Viewer for the whole project and update their permission on that environment type to Contributor.
The project owner - the person licensed to use Platform.sh - has the project administrator role. The project owner is the only user that can make changes to the project plan.
By default, everyone with access equal or greater than Contributor can access the project through SSH.
To customize who can use SSH, set the
access key in your
From your list of projects, select the project where you want to view or edit user permissions. Click the Settings tab at the top of the page, then click the
Access tab on the left to see the users in the project and their roles.
Selecting a user to edit that user’s permissions or delete the user’s access to the project entirely.
To add a new user, click the
You can either grant the
Project admin role to the user, which will give them
Admin access to every environment in the project, or grant specific permissions for each environment type.
After inviting a new user, users without a Platform.sh account receive an invitation email asking to confirm their details and register an account.
In order to push and pull code (or to SSH into one of the project’s environments), the user needs to add an SSH key or use the Platform CLI.
If the user already has an account, they receive an email with a link to access the project.
You can use the Platform.sh CLI (Command Line Interface). to fully manage your users and integrate with any automated system.
- Add a user to the project
- Delete a user
- List project users
- View or change a user’s role
For example, the following command would add
firstname.lastname@example.org with Project Admin role in the current project.
platform user:add email@example.com -r admin
firstname.lastname@example.org, Alice will receive an invitation email asking to confirm her details and optionally, register for a Platform.sh account.
To give Bob different levels of access depending on the environment type, in the current project:
- Viewer role to the Production environment
- Contributor role to all Staging type environments
- Admin role to all Development type environments
You would run:
platform user:role email@example.com -r production:viewer -r staging:contributor -r development:admin
platform list to get the full list of commands.
If you have setup an external integration to GitHub, GitLab, or Bitbucket, this adds an additional layer of access control to the project that you will need to be aware of.
For example, if you invite a user with Project Admin role to a project on Platform.sh, but you haven’t invited them to the remote repository on GitHub / GitLab, they might be unable to clone the project locally.
In this example, using either
platform get with the CLI:
$ platform get <projectID>
git clone command visible from the “Git” dropdown in the management console
$ git clone firstname.lastname@example.org:user/github-repo.git Project Name
both would error with
Failed to connect to the Git repository: email@example.com:user/github-repo.git Please make sure you have the correct access rights and the repository exists.
despite their Project Admin access to the project.
This enhaces consistency over your source code, as the Platform.sh project functions as a read-only mirror of your remote repository. Otherwise, changes pushed directly to the project would be overwritten or deleted when commits are pushed via the integration. Platform.sh considers your integrated remote repository to be the “source of truth” as soon as it has been configured, and this caveat ensures that all commits go through the integration.
The best course of action is to have your access updated on the integrated repository. If for some reason that is not a quick change, you can still clone through the project using the legacy pattern (which will set the project as its remote), but again, it is not recommended that you commit to the project once you have done so:
$ git clone <project>@git.<region>.platform.sh:<project>.git
If you’re the owner of a project, and want to transfer it to a different user, first invite that user as a project administrator and then submit a support ticket from your owner account to ask for the transfer.
Transfering a project automatically transfers the upcoming subscription charges to the new owner.