DigitalOcean’s team and permission system lets you delegate access to your Droplets, databases, and other resources without giving away your root credentials.
Let’s see it in action. Imagine you’ve got a web server (Droplet my-web-server) and a managed PostgreSQL database (my-pg-db). You need to bring on a new developer, Alex, who will only be working on the web server and shouldn’t touch the database.
First, you’d invite Alex to your DigitalOcean account.
# On your DigitalOcean account, navigate to "Team"
# Click "Invite Members"
# Enter Alex's email: alex@example.com
# Assign a role: "Developer"
The "Developer" role is a built-in role that has read-only access to everything and can manage Droplets, but cannot manage billing or access sensitive resources like SSH keys or databases by default.
Now, Alex can log in. But Alex still can’t do anything specific. You need to grant access to my-web-server.
# As the account owner, navigate to "Droplets"
# Click on "my-web-server"
# Go to the "Access" tab
# Under "Team Access", click "Grant Access"
# Select Alex from the dropdown
# Click "Grant Access"
Alex can now SSH into my-web-server and make changes. Alex can see my-pg-db listed in their dashboard, but if they try to click on it, they’ll get an "Access Denied" error. This is because the "Developer" role doesn’t automatically grant access to all resources, only allows them to be granted access.
What if Alex did need to manage the database, but only specific aspects? You’d create a custom role.
# On your DigitalOcean account, navigate to "Team"
# Click "Roles"
# Click "Create Role"
# Name: "DB Admin Lite"
# Permissions:
# - Read: Databases
# - Write: Databases
# - Read: Droplets
# - Write: Droplets (if needed, but let's assume not for this example)
# - Read: Projects
# - Write: Projects
# - Read: SSH Keys (usually not needed for DB admin)
# - Read: Load Balancers
# - Read: Firewalls
# Click "Create Role"
Now, you’d assign this "DB Admin Lite" role to Alex.
# On your DigitalOcean account, navigate to "Team"
# Find Alex in the member list
# Click the three dots next to Alex's name
# Click "Edit Role"
# Select "DB Admin Lite"
# Click "Update Role"
With this, Alex can now manage all databases (read and write), but still only has read-only access to Droplets if that was the only other permission granted. The key here is that roles define capabilities, and resource grants define applicability of those capabilities.
The entire system is built around a granular, role-based access control (RBAC) model. You define roles with specific permissions (e.g., read:droplets, write:databases, manage:billing). Then, you assign these roles to team members. Finally, for resources like Droplets, Kubernetes clusters, or managed databases, you explicitly grant access to specific resources to individual team members or roles. This means a team member can have the "Developer" role (which grants them the ability to manage Droplets) but only have access to Droplets in a specific project if you grant it.
When a team member attempts an action, DigitalOcean checks:
- Role Permissions: Does their assigned role permit this type of action (e.g.,
write:droplets)? - Resource Access: If the action is allowed by the role, is this specific resource (e.g.,
my-web-server) explicitly granted to them or a role they belong to?
The most surprising thing is that the default "Developer" role, while seemingly broad, is actually quite restrictive in practice because it requires explicit resource grants for most actions beyond basic Droplet management. Many users assume "Developer" means they can touch anything they can see, but it’s just a baseline capability set that needs to be applied to specific resources.
Here’s a common scenario: a team member can see a Droplet, can SSH into it, but gets an error when trying to resize it. This is because the "Developer" role grants read:droplets and write:droplets, but the resource-level access grant for that specific Droplet might only include read:droplets or no write permissions at all. To fix this, the account owner must go to the Droplet’s "Access" tab and explicitly grant "Resize" permissions for that Droplet to the team member or their role.
The next thing you’ll likely want to tackle is managing access to projects, which is the primary organizational unit for grouping resources and applying team access policies at a higher level.