Workspaces, multi-user access control, and API keys/tokens are not part of Geti v3.0

[yvolokitin]

Description:
We want to clarify the scope of the current release regarding user management and authentication.

In Geti v3.0, the following capabilities are not included:

Workspaces – workspace-based organization and isolation of projects.
Multi-user access control – role-based permissions, user invitations, and team management.
API keys / tokens – API-based (programmatic) authentication for accessing Geti services.
Geti v3.0 is designed as a single-user deployment, so these multi-user and token-based authentication features are intentionally out of scope for this version.

If you have use cases that depend on any of these capabilities, please share them in the comments — it helps us prioritize future work.

Impact: Existing API keys/tokens do not carry over and are not required.
Action required: Update integrations to the new REST API/clients, which do not rely on personal access tokens.

[UomoCaffeLatte]

Hi,

What was the reason for this shift in focus from being a collaborative tool to standalone? We use it extensively for generating annotations with a pool of dedicated annotators in which workspace and multi-user access control is essential. Hence, there is no possible way to upgrade to v3 without moving to standalone installations per user. I understand this would open up the platform to more users but it disregards collaborative usage.

Will this feature ever be revisited or is the direction of the geti platform firmly on a standalone user application from now on. For example, would we

Thanks,
Nikhil

[yvolokitin]

Hi @UomoCaffeLatte Nikhil, thank you for the detailed feedback and for sharing your annotator workflow.
You are absolutely right: for teams using shared workspaces, roles, and controlled access, v3.0 single-user is not a drop-in replacement for that collaboration model.

The short answer is that v3.0 was intentionally scoped as a simpler single-user deployment to improve portability and ease of setup (desktop/single-container), and multi-user IAM/workspaces were out of scope for this release. This is a scope change, not a signal that collaborative use cases are unimportant.

For now, if you need team collaboration with access control, we do not recommend migrating that workflow to a single shared v3.0 instance. The current options are:

• use isolated per-user v3.0 instances only for standalone use cases

• stay on your existing collaborative deployment path for team annotation workflows,

We are actively collecting requirements for future multi-user capabilities, but we cannot commit to a timeline yet. If you can share your expected setup (number of annotators, project isolation model, reviewer roles, SSO/API-token needs, and audit/compliance requirements), that will directly help us shape prioritization and design.

Thanks again for raising this clearly.