Access Management

Control who can access and manage your Skysize projects with role-based access control.

Access Roles

Each project grants access with one of four roles: Admin (full control), Maintainer (sees everything, full control of staging), Developer (development branches only) and User (read-only). A person's role on a project can be granted directly (added to the project) or through a group they belong to (see Groups below).

User Role

Users have view-only access to the project.

Permissions:

• View project details
• See deployment and build status
• Monitor application health, metrics, and logs
• View configuration (but not modify it)

Use cases:

• Stakeholders who need visibility
• Clients who want to monitor progress
• Team members who don't need to make changes
• Read-only access for reporting

Admin Role

Admins have full control over the project.

Permissions:

• All User role permissions, plus:
• Create, update, rebuild, and delete deployments
• Modify project and branch configuration
• Manage Odoo workers and time limits
• Configure custom domains and SSL
• Manage project access (invite/remove members, change roles)
• Create, restore, download, and delete backups

Use cases:

• Project managers
• DevOps engineers
• Lead developers
• Technical administrators

Maintainer Role

Maintainers see everything and have full control of staging, but cannot touch production. The role is built for junior developers, functional consultants and internal staff who need full visibility and a place to test, such as an Odoo upgrade or an older backup, without being trusted with production.

Permissions:

• All User role permissions, plus:
• Read the Odoo logs, slow queries and health details of every branch, production included
• Log in as any Odoo user on every branch (every login is recorded in the audit log)
• Read the audit log, the members and the pending invitations
• Take and download backups on every branch
• Full control of staging branches: rebuild, restart, delete the deployment, change the branch settings, restore or import a backup
• Switch a branch between staging and development
• Full control of development branches, like the Developer role

What a Maintainer cannot do: change, rebuild, restart, delete or restore anything on production, restore a backup into a development branch, make a branch production, manage the project settings, members, domains or billing.

caution

Rebuilding a staging branch starts it over from a fresh copy of production, and restoring a backup into it replaces its database: data entered on staging since then is lost.

Developer Role

Developers have full control over development branches and their demo data, and no access to production or staging data. The role is built for external contractors.

Roles at a glance

	User	Developer	Maintainer	Admin
View deployments, builds, metrics	✅	✅	✅	✅
Production and staging logs	✅	❌	✅	✅
Log in as an Odoo user	❌	development only	✅	✅
Read the audit log	❌	❌	✅	✅
Take and download backups	❌	❌	✅	✅
Rebuild / restart	❌	development only	staging and development	✅
Delete deployments	❌	development only	staging and development	✅
Restore or import backups	❌	❌	staging only	✅
Settings, members, domains	❌	❌	❌	✅

User Management

Project admins invite team members by email and assign them a role:

1. Navigate to the project's Access Management section.
2. Invite a user by email address and choose their role.
3. The invited person receives an email with a link to accept or reject the invitation.
4. Once accepted, their access takes effect immediately.

Invitation details:

• Invitations expire after 7 days if not accepted.
• An invitation can only be accepted by the email address it was sent to.
• A pending invitation can be withdrawn by an admin before it is accepted.

note

You can grant access to individuals by email or to a whole group at once. Group-based access is convenient for managing stable teams across several projects.

Deployment Operations

Admins can perform critical deployment operations:

• Create new deployments: Launch new builds.
• Update deployments: Deploy the latest code changes.
• Rebuild deployments: Recreate a deployment with a fresh database (for example, a new production snapshot for staging).
• Delete deployments: Remove deployments that are no longer needed.

note

Skysize does not expose a one-click "rollback to a previous version" action. Instead, updates are rollback-safe: if an update fails its health check, the platform automatically restores the deployment to its previous working state. To deliberately return to an earlier state, restore a backup.

Best Practices

Principle of Least Privilege

Grant users the minimum level of access needed for their role:

• Give User access to stakeholders who only need visibility
• Reserve Admin access for team members who actively manage deployments

Regular Access Reviews

Periodically review who has access to your projects:

• Remove users who no longer need access
• Ensure roles are still appropriate
• Audit admin permissions regularly

Team Organization

Structure your team access logically:

• Admins: DevOps engineers, lead developers, project managers
• Users: Stakeholders, clients, junior developers, QA team

Security Considerations

• Limit admin access: Not everyone needs full control
• Use strong authentication: Ensure all users have strong passwords
• Remove inactive users: Clean up access for users who leave the team
• Monitor changes: Keep track of who makes configuration changes

Managing Access

Adding Users

1. Go to your project settings
2. Select "Access Management"
3. Click "Add User"
4. Enter the user's email address
5. Select their role
6. Send the invitation

Modifying Access

1. Navigate to the user list in project settings
2. Find the user you want to modify
3. Change their role or remove their access
4. Changes take effect immediately

Removing Access

1. Go to project access management
2. Find the user to remove
3. Click "Remove Access"
4. Confirm the action

The user will immediately lose access to the project.

caution

A project must always keep at least one admin. You cannot remove the last remaining admin, and you cannot downgrade the last admin to a User role. Add another admin first if you need to change the current one.

Groups: Team-Based Access

Instead of inviting people to each project one by one, you can manage access with groups. A group is a named set of users; granting a group access to a project gives every member of that group the assigned role on that project.

How it works:

• A user can be a member of one or more groups.
• A group is given a role (User or Admin) on a project.
• Every member of the group inherits that role on the project.
• A user's effective access is the combination of their direct project roles and any roles they get through groups.

Why use groups:

• Onboard a new team member once (add them to the right group) and they get access to all the projects that group covers.
• Manage access for whole teams (for example, "QA" or "Developers") in one place.
• Reduce the risk of stale, per-project permissions when someone changes teams.

In the project's member list, access granted through a group is distinguished from access granted directly, so you can always see why someone has access.