Team & Permissions

Right Access,
Right People

Give designers, contractors, and finance the access they actually need — and nothing more. Three permission layers, Teams for larger orgs, and a "most permissive wins" rule that makes overlapping access predictable.

Unlimited users on every plan
Account, project & server-level scopes
Teams on Business & Enterprise

Last updated on 18th May 2026

DeployHQ permissions are layered: every grant lives at one of three levels — account, project, or server. Permissions stack from broad to narrow, and when multiple grants overlap, the most permissive wins. That's it — no role matrix to memorise.

Three Permission Layers

Each layer answers a different question. Grant only what each role actually needs.

Account

What can they touch across the account?

  • Account administrator — full access, including billing
  • Manage users — invite, edit, remove
  • Manage billing — payment methods, invoices, plan changes
  • Manage agents — network agents for firewalled servers
  • Create projects — spin up new projects
Project

Which projects can they see and edit?

  • All projects — every project in the account
  • Specific projects — pick the ones they need
  • Update configuration — non-sensitive project settings
  • Manage config files — create, edit, delete
  • Cannot delete — protected unless explicitly granted
Server

Where in a project can they deploy?

  • Any server — deploy to anything in the project
  • Specific servers — only the targets you list
  • Server groups — grant access by environment
  • No deploy — read access without the deploy button
  • Per-project — server permissions are project-scoped

Teams — Permissions That Scale

Stop setting permissions one user at a time. Teams group users together, share permissions, and inherit project access. Available on Business & Enterprise.

Group users, share permissions

Instead of clicking through each user every time you add a project, create a team like "Deploy Engineers" or "Agency Clients", give it the permissions and project access once, and add users to inherit it.

All Projects, with exclusions

When a team is set to "All Projects", you can still mark specific projects as off-limits — useful when one or two projects contain sensitive credentials that only certain people should see. The team listing shows "All Projects (N excluded)" so you always know the score.

Users in multiple teams

A user can belong to multiple teams; their effective permissions are the union of every team they're in plus any direct user grants. DeployHQ applies the "most permissive wins" rule consistently across all overlapping grants.

Team Deploy Engineers
All Projects (2 excluded)
AB MK JR +5
Team Agency Clients
Specific Projects · 3 selected
TL CN
Team Finance
Billing only · No project access
PD
The one rule

Most permissive access wins

When a user has the same project granted through multiple routes — say, a team that includes it plus a direct assignment — the broadest grant is the one that applies. Excluding a project from one team doesn't hide it if another route still grants access. That keeps the model predictable and explicit.

  • Excluding a project on Team A doesn't hide it if Team B grants it
  • Direct user assignment always coexists with team grants
  • To remove access, remove every route that grants it

Real-World Setups

Common patterns we see across agencies, in-house teams, and regulated industries.

Agency with client isolation

One team per client, each scoped to that client's projects only. Add contractors to the relevant team for the duration of the engagement; remove them when it ends. Clients never see each other's projects.

Finance access without deploy keys

A "Finance" team with Manage billing enabled and no project access. They see invoices and update payment methods but cannot deploy, view code, or touch infrastructure.

Junior devs locked to staging

Project access enabled, but server permissions restricted to the staging server group. They can deploy freely to staging and never accidentally promote a change to production.

Sensitive projects, broad team

"Deploy Engineers" team gets All Projects access, but two projects (containing sensitive infrastructure) are listed as exclusions. Only the two named admins on those projects can see them.

Getting Started

Invite your first teammate in under a minute

Check mark

Open User Management

Settings → Account → User Management. Click New User.

Check mark

Pick the scope

Account permissions (admin, billing, agents), then project access (all or specific). Drill into server access if you need finer control.

Check mark

Or build a Team (B/E plans)

Settings → Account → Team Management. Create a team with the permissions you want, then drop users in. They inherit everything automatically.

Read the documentation →
PERMISSION LAYERS ACCOUNT admin · users · billing · agents · create PROJECT all projects · specific · config SERVER per-server / per-group Stacks from broad to narrow · most permissive wins

Frequently Asked Questions

How many users can I have on a DeployHQ account?

There is no seat limit. Add as many users as you need on every plan — pricing is based on projects and channels, not headcount. This is unusual in the deployment-platform market and makes DeployHQ a strong fit for agencies and large in-house teams.

Are Teams available on every plan?

Individual user permissions are available on every plan. Teams (group-based permissions with shared project access) are available on Business and Enterprise plans. If you're on a smaller plan and want team-level grouping, upgrading is the way in.

How does DeployHQ handle overlapping permissions?

The most permissive grant wins. If a user has the same project granted through Team A and a direct user assignment, the broader of the two applies. To revoke access, remove every route that grants it — excluding a project from one team doesn't hide it if another team or direct grant still includes it.

Can I restrict a user to deploy only to certain servers?

Yes. After granting project access, you can switch off 'can deploy to any server' and add per-server or per-server-group permissions. A common pattern is to let junior devs deploy to staging freely and require a separate role for production.

Does DeployHQ support 2FA and SSO?

Two-factor authentication is supported across every plan, including SMS recovery via Twilio. Single sign-on with your identity provider is available on Enterprise plans.

Bring your whole team — give each one the right keys

Unlimited users on every plan. No per-seat invoices to apologise for.

10-day free trial • No setup fees • Cancel anytime

Get started today for just $9/month

That's unlimited deployments and 3 projects.

Start your free 10 day trial