Access control¶

Wodby access is layered. A user can have:

an organization role
one or more team memberships
one or more direct project memberships
project access inherited from teams

These layers answer different questions:

Can the user enter the organization?
Can the user administer organization-wide settings?
Can the user see, create, or change resources in a project?
Can the user use a resource that belongs to another project or to the organization?
Can the user reveal a stored credential as readable text?

Organization roles¶

Organization membership is the top-level access gate. A user must have an active organization membership before any project or resource access can apply.

Role	Meaning
`Owner`	Full access to organization resources and billing. Owners can manage other owners.
`Admin`	Full access to organization resources, projects, teams, and org-owned resources. Admins do not manage billing, termination protection, owners, or other admins.
`Member`	Works through project access. Members do not receive organization-wide resource access by default.
`Support`	Read-only access across the organization.
`Robot`	Internal automation role. Robot users are not assigned to teams or projects and are not managed through normal membership workflows.

Organization owners and admins have full resource access across the organization. Project roles matter most for organization members.

Support and robot users cannot be invited as normal users and cannot be assigned to teams or projects.

Membership management¶

Organization membership changes follow role hierarchy rules.

Owners can manage owners, admins, and members.
Admins can manage members, but not owners or other admins.
Members cannot manage organization memberships.
Support and robot memberships are not managed through the normal organization membership UI.

When an organization membership is removed, Wodby also removes that membership from teams and direct project memberships.

Teams¶

Teams are reusable groups of organization members. Use teams when the same people need the same project access in several places.

Team roles are:

Role	Meaning
`Member`	Regular team member. Receives project access assigned to the team.
`Team leader`	Can view that team. Receives project access assigned to the team.

Organization owners and admins can create, update, and delete teams. They also manage team members and team leaders.

Teams can be added to projects with Read or Write access. Teams cannot be assigned the project Admin role. Project administration is only granted directly to specific organization members.

Project roles¶

Projects are the main day-to-day permission boundary. Project access can be granted:

directly to an organization member
indirectly through one or more teams

Project roles are:

Role	Meaning
`Read`	View the project and resources visible in it. `Read` also means the resource can be selected or referenced by workflows that only need use access.
`Write`	Create and modify resources inside the project. `Write` includes `Read`.
`Admin`	Manage the project itself, including project access and project settings. `Admin` includes `Write`.

If a user receives project access more than one way, Wodby uses the highest effective role.

Example:

direct project membership is Read
team project membership is Write
effective project role is Write

Team-derived project access is capped at Write. Even if older data contains an admin role for a team, Wodby treats that team role as Write during access checks.

Project access is managed from Organization > Projects > [Project] > Access.

Users with access to this page can see project memberships. Organization owners/admins and project admins can:

add organization members
add teams
assign direct user roles
assign team roles
change roles later
remove project memberships

Secret reveal permissions¶

Write access and permission to display a stored secret are separate. This lets a developer manage and deploy an app without automatically receiving every credential that Wodby stores for it.

For project-owned resources, direct secret reveal follows this table:

Effective access	Runtime secrets	Privileged secrets
Organization owner or admin	Allowed	Allowed
Project `Admin`	Allowed	Allowed
Project `Write` with `Reveal runtime secrets` enabled	Allowed	Not allowed
Project `Write` without `Reveal runtime secrets`	Not allowed	Not allowed
Project `Read`	Not allowed	Not allowed

Runtime secrets currently include app-service tokens, app endpoint-auth passwords, and database-user passwords. Privileged secrets currently include database master or root passwords. Organization-owned secrets can be revealed only by organization owners and admins.

Reveal runtime secrets can be enabled for a direct Write membership or for a team with Write access. It is not available for Read; project Admin includes both reveal scopes automatically. If a user has several effective Write memberships, runtime reveal is enabled when at least one of those memberships enables it. Access through a project that merely shares the resource does not grant direct reveal—the permission is evaluated through the resource's owner project.

Existing Write assignments may initially have runtime reveal enabled to preserve their previous access. Project administrators should review those assignments from the project's Access page and disable the capability where it is not needed.

Every direct reveal also requires an interactive user session with a recent login or step-up confirmation. Depending on the account, Wodby asks for a password, authenticator/recovery code, or a code sent to the verified primary email. See Secret reveal confirmation.

Runtime access is broader than the reveal button

Secret reveal permission controls whether Wodby displays a stored value through its dashboard/API reveal operation. It does not prevent an authorized workload from receiving its configured credentials. A user with writable app and web-terminal access may be able to inspect credentials already injected into that runtime. Treat project Write as trusted application-operator access even when direct secret reveal is disabled.

Permission meanings¶

Wodby uses the same basic permission meanings across resource types.

Permission	Meaning	Typical requirement
Read/use	View, select, or reference an existing resource in supported workflows	Project `Read` on the owner project or a project with `Read/Use` or `Modify/Delete` sharing, or org-wide view access where the resource is organization-owned
Create in project	Create a new project-owned resource	Project `Write` or `Admin`, or organization owner/admin
Create in organization	Create a new organization-owned resource	Organization owner/admin
Modify/delete	Change or remove the resource itself	Organization owner/admin for organization-owned resources. Owner-project `Write` or `Admin`, or organization owner/admin, for project-owned resources
Ownership & sharing	Change the resource owner or project access list	See Resource ownership. The requirement depends on whether the resource is organization-owned or project-owned
Manage project	Rename, delete, or manage project access	Project `Admin`, or organization owner/admin
Manage organization/team	Manage org settings, teams, team members, and team leaders	Organization owner/admin
Manage termination protection	Change organization-wide deletion safeguards	Organization owners only
Manage org members	Invite, change roles, or remove organization members	Owners can manage owners/admins/members. Admins can manage members only
Manage billing	Change subscription, billing details, invoices, or spending limits	Organization owners only

What read means¶

In Wodby, Read is not only inspection. For reusable resources, read access also means use access.

For example, if a user can create an app in Project A and Project A can read a cluster, stack, integration, service, provider, or database, that resource can be selected where the workflow allows it.

Typical read/use examples:

deploy an app to a visible Kubernetes cluster
create an app from a visible stack
attach a visible integration to an app service
use a visible service, provider, or database in a supported workflow

The user still needs write access to the target object they are creating or modifying. For example, deploying an app requires write access in the app's project even if the selected cluster only needs read/use access.

Resource-specific checks still apply. A resource may need to be in an OK status, belong to the same organization, provide the right integration type, or satisfy stack/service compatibility rules.

Read/use access for the user is necessary but does not by itself make an organization/project-scoped resource a valid dependency. A project-owned target can reference resources owned by or shared with its owner project. An organization-owned target can reference only organization-owned resources in the same organization. See Sharing.

Resource ownership¶

Resources can be owned at either organization scope or project scope.

Supported owned resource types include:

apps
Kubernetes clusters
databases
integrations
providers
services
stacks

Organization-owned resources¶

Organization-owned resources belong to the organization rather than to one owner project.

Access rules:

Action	Allowed users
Read/use	Organization owners, admins, support users, or users who can access a project with `Read/Use` or `Modify/Delete` access
Modify/delete	Organization owners and admins
Ownership & sharing	Organization owners and admins

Regular organization members do not automatically see organization-owned resources. They can see and use an organization-owned resource only when it is shared with a project they can access.

Project-owned resources¶

Project-owned resources have one owner project. The owner project always has Modify/Delete access, and additional projects can receive either Read/Use or Modify/Delete access through sharing.

Access rules:

Action	Allowed users
Read/use	Users who can access the owner project or any shared project
Modify/delete	Users with `Write` or `Admin` access to the owner project, plus organization owners/admins
Ownership & sharing	Organization owners/admins. For project-owned resources that remain project-owned, users with owner-scope write access can update sharing or owner project when they also have project `Admin` access to every affected project

Sharing a project-owned resource to another project does not move ownership. A Read/Use share grants visibility and use only. A Modify/Delete share includes read/use and marks the project-resource link as write-capable for project-scoped ACL checks, but direct resource update/delete mutations still require access through the owner project or organization admin/owner access.

Sharing makes a resource visible or usable outside its owner scope. A Modify/Delete share also marks the project-resource link as write-capable for workflows that check project-resource access.

Use sharing when:

several projects should deploy to the same Kubernetes cluster
several projects should use the same integration
one project should consume a stack, service, provider, or database owned elsewhere
an organization-owned resource should be available to selected project members

Sharing does not grant project administration rights and does not transfer ownership.

Project access entries have two access levels:

Read/Use lets the target project view, select, or reference the resource.
Modify/Delete includes Read/Use and marks the project-resource link as write-capable for workflows that check project-resource access.

For organization-owned resources, only organization owners and admins can change the resource owner or project access list. Changing any resource to organization ownership also requires organization owner/admin access. For project-owned resources that remain project-owned, a user must have resource write access through the owner scope and Admin access to each project whose share or owner is changed. Organization owners and admins satisfy these checks across the organization.

See Sharing for the user-facing sharing workflow.

Tasks¶

Tasks inherit access from the resources and projects they reference.

Project-linked tasks are visible through their linked projects.
A task linked to several projects is visible if the user can access at least one linked project.
Project-linked tasks can be repeated by organization owners/admins and project members who can access at least one linked project.
Project-linked tasks can be cancelled or otherwise modified only by organization owners and admins.
Project-linked tasks do not fall back to general organization membership if the user cannot access any linked project.
Tasks without project links are treated as organization-scoped tasks.

Organization-scoped tasks can be read by roles with organization-wide visibility. They can be repeated, cancelled, or otherwise modified only by organization owners and admins.

Apps and app instances¶

Apps can be organization-owned or project-owned. In the dashboard, the app creation Owner field accepts either Organization <organization> or Project <project>. Creating an organization-owned app requires organization owner/admin access. Creating a project-owned app requires write/admin access in the owner project, or organization owner/admin access.

During app creation, referenced resources such as clusters, stacks, integrations, services, providers, and databases generally require read/use access, not modify access. A shared cluster can therefore be a valid deployment target for a project-owned app without granting cluster write access, provided the cluster is shared with the app's owner project. Organization/project-scoped dependencies for an organization-owned app must be organization-owned in the same organization.

App instances do not have a separate project owner. They belong to the app and use the app's ownership and sharing settings. Container-based databases created for app services follow the same rule: their owner and project access list stay synchronized with the app and cannot be changed independently. Managed databases keep their own ownership and sharing settings.

Changing an existing app, app instance, app service, deployment, build source, environment variables, tokens, annotations, routes, ports, auth settings, and similar app-owned configuration requires modify access to the app or app instance.

Practical examples¶

Shared cluster¶

Project Platform owns a Kubernetes cluster. Project Web can read/use that cluster through a Read/Use share.

A Project Web writer can deploy an app from Project Web to the shared cluster.
The same user cannot scale or delete the cluster unless they also have write/admin access to the owner project or organization admin/owner access.
The same user cannot change ownership or sharing unless they have owner-scope write access and Admin access to the affected projects, or organization admin/owner access. Changing the cluster to organization ownership requires organization admin/owner access.

Organization-owned integration¶

An organization admin creates a GitHub integration at organization scope and shares it with Project API as Read/Use.

Project API users can select the integration in supported workflows.
Only organization owners and admins can modify or delete the integration.

Team access¶

A Developers team is added to Project App with Write.

Team members can create and update resources inside Project App.
Team leaders can view the Developers team, but organization owners/admins manage team membership.
The team cannot be project admin. Project admin must be granted directly to specific users.