Granular Permissions in Organizations
Granular permissions control what each member can view or change inside an organization. They improve security by reducing broad access and allowing only the actions each person needs.
In practice, you can let a user view only one project, read logs without changing settings, trigger deploys without accessing billing, or manage payments without touching environment variables.
Access model
Access combines three elements:
| Element | Purpose |
|---|---|
| Role | Defines the member's base level: owner, assistant, or member |
| Resource | Defines the affected area, such as project, database, GitHub, billing, AI key, or global API key |
| Action | Defines the allowed operation, such as reading logs, changing environment variables, or creating checkout |
The owner has full access to the organization. For assistant and member, permissions can be broader or stricter depending on the resource and action.
Protected resources
Permissions can be applied to different organization resources.
| Resource | Access examples |
|---|---|
| organization | Create projects, invite members, update permissions |
| project | View project, logs, metrics, variables, domain, network, instances, and image |
| database | View status, access connection, rotate password, and update version |
| github | View configuration, update integration, trigger deploy, and inspect builds |
| ai_key | Create, view, delete keys, and inspect AI usage |
| api_key | View and revoke global organization API keys |
| billing | View billing, transactions, checkout, and payment methods |
Some permissions are sensitive and should be granted carefully. Access to environment variables, database connection data, billing, and deploy changes can affect operations, security, or costs.
Resource scope
Permissions can be granted for every resource of a type or for a specific resource. For example, a member can receive access only to the staging project without viewing production projects.
Examples:
- access to logs and metrics for one project;
- permission to update the image for all projects in an organization;
- permission to view connection data for a specific database;
- permission to revoke a specific global API key;
- read access to billing without permission to configure payment;
- authorization to trigger GitHub deploys without changing the integration.
This scope prevents people with limited responsibilities from seeing or controlling resources outside their work.
Recommended roles
Use roles as a starting point and adjust permissions as needed.
| Profile | Recommended configuration |
|---|---|
| Founder or main administrator | owner, with periodic member review |
| Technical lead | assistant, with operational access to the required projects |
| Developer of one service | member, with access to the specific project, logs, metrics, and deploy |
| Finance analyst | member, with billing and transaction read access |
| Support user | member, with logs and metrics read access, without environment changes |
Avoid making every collaborator an assistant. The broader the role, the higher the impact of human error, compromised credentials, or unplanned changes.
Practical examples
Developer with access to one project
Grant project read access, logs, metrics, and deploy only for the specific resource. If the person also needs to change environment variables, add that action explicitly.
Billing owner
Grant billing and transaction read access. Allow payment configuration or checkout creation only when the person is actually responsible for payment methods.
Database operator
Grant status and connection access for the specific database. Password rotation and version updates should remain restricted to authorized people.
Security best practices
- apply the principle of least privilege;
- prefer project-scoped access in critical environments;
- review permissions when someone changes roles;
- remove members who no longer participate in the organization;
- limit access to billing, secrets, and deploy configuration;
- use individual accounts, never shared credentials.
Granular permissions are most effective when they are part of a governance routine. Review members and permissions at defined intervals, especially in organizations with production systems, sensitive data, or relevant costs.
Next steps
- Understand organizations in Zenifra
- Invite members to an organization
- Create organization API keys
- Configure your account security
FAQ
Does owner need manually configured permissions?
No. The owner has full access to the organization.
Can I allow access to only one project?
Yes. Permissions can be applied to specific resources, allowing limited access to one project or database.
Do permissions replace account best practices?
No. Use granular permissions together with strong passwords, 2FA, member review, and removal of unnecessary access.