Skip to content
Ronja Docs

Grant a maintainer

A maintainer is a person — or every member of an access group — whom an Admin has put in charge of one organization-scoped feature. Inside that feature they build and approve much as an Admin would, with the exceptions below. Everywhere else, nothing changes for them.

You grant, list and revoke maintainers in the feature’s Settings, in the Access section. The same actions are also available through Ronja’s API.

What a maintainer can do

Section titled “What a maintainer can do”
  • Create, edit and delete everything inside the feature — tables and their data, apps, workflows, notes, secrets, automations, Saved Agents, MCP servers, codexes and modules — and rename the feature or change its description. A Saved Agent someone else authored stays with that author or an Admin.
  • Create resources there that go live directly, instead of becoming proposals. Modules are the exception: in a shared feature every new module starts as a proposal, an Admin’s included, and an Admin approves it.
  • Approve colleagues’ proposals for notes, workflows, apps and Saved Agents, and commit table, workflow and app drafts — a colleague’s once submitted, their own without submitting it unless your organization disallows self-approval.

Maintainer access changes what someone can edit. It never changes what they can read: a maintainer sees what they could already see.

Some things stay with an Admin: changing the feature’s scope, moving, deleting or exporting it, making anyone a maintainer, committing a change to a live note, Saved Agent or module, and rejecting a draft. Creating a table, or running Build or Fix on one, also stays Admin-only over the API and the CLI — a maintainer asks Ronja in a chat for those. The roles matrix has the full list, and Scopes and sharing explains the model.

Grant maintainer access

Section titled “Grant maintainer access”
  1. Open the feature and click Access, next to Share at the top of the page. (You can also click Settings and scroll to Access.)
  2. Under Add maintainer, choose Person or Access group.
  3. Pick them from the list — Choose a person lists the members of your organization, Choose an access group lists your access groups.
  4. Click Add maintainer.

The feature must be organization-scoped and not in the Trash. On a private feature, the Access section says maintainers apply to organization-scoped features only and offers nothing to add.

An access group’s maintainer access covers everyone in it, including people added to it later. If you pick an access group that contains every member of your organization, Ronja asks you to confirm and tells you how many people that is, because it makes every colleague a maintainer — a different decision from putting one team in charge. Click Make everyone a maintainer to go ahead.

Adding a person or access group that is already a maintainer changes nothing.

When Ronja warns you

Section titled “When Ronja warns you”

Maintainer access changes what someone can edit, not what they can see. If the person or access group can’t see the feature, or can see only some of its contents, Ronja still makes them a maintainer and shows Admins a warning on their row — for example, that they are not in an access group that can see this feature, or that their access groups see only some of the resources in it that access groups can restrict. They can’t change what they can’t see. Admins are never warned about, because an Admin already sees the whole organization. To fix it, give their access group access to the feature, or to more of its tables; see Access groups.

See who maintains a feature

Section titled “See who maintains a feature”

The Access section lists every maintainer: the person or access group, who granted it and when. An Admin sees it on every feature; a maintainer sees it, read-only, on the feature they maintain — the Access button appears for them too. Everyone else sees a short note instead.

A row marked Inactive does nothing right now. That happens when the feature was made private or moved to the Trash, the access group was deleted, or the person is no longer a member of your organization. Remove it, or undo what changed.

See every maintainer at once

Section titled “See every maintainer at once”

Admins don’t have to open each feature to find out who maintains what:

  • On the Shared features page, each row of the Features × access groups map shows that feature’s maintainers after its kind and creation date — a person’s initials or an access group’s icon with the name, at most two, then +N. An Inactive grant is greyed out and struck through, and a feature with no active grant reads No maintainer, followed by any inactive ones. Click them to open the feature’s Access section.
  • Maintained by, beside the name and Tag filters, narrows the map to the features one person or access group maintains, or to No maintainer — features where no grant is active. Choosing a person includes the features they maintain through an access group they belong to. Choose Anyone, or click the × on the filter, to clear it.
  • On Users & Access, open a person’s Settings: the Maintains section lists every feature they maintain, once each, linking to the feature. Beside it is how they hold it: directly, via an access group’s name, or both. A feature where none of their grants is active is greyed out and marked Inactive, and a feature in the Trash is not linked and is marked In the trash. Someone with no grants shows “Not a maintainer of any feature.”

The reach warnings appear only in each feature’s Access section.

Revoke maintainer access

Section titled “Revoke maintainer access”

Click Remove on the maintainer’s row. It applies from their next change, and it does not undo what they built or connected while they held it.

Use the API instead

Section titled “Use the API instead”

Granting needs a person signed in to Ronja. The CLI, API tokens, automations and Ronja herself are all refused with human_required — see Actions the API can’t take. Listing and revoking can be scripted.

To grant, send POST /api/v2/feature/<feature ID>/maintainers with exactly one of userID (a member of your organization) or workspaceID (an access group):

{"userID": "<user ID>"}

An access group that contains every member of your organization also needs "acknowledgeAllUsers": true:

{"workspaceID": "<access group ID>", "acknowledgeAllUsers": true}

The response is the grant; keep its id, because you need it to revoke. It carries the same warnings the Access section shows.

To list, and to revoke:

Terminal window
ronja api /api/v2/feature/<feature ID>/maintainers
ronja api -X DELETE /api/v2/feature/<feature ID>/maintainers/<grant ID>

To list every grant in your organization at once, send GET /api/v2/feature/maintainers, optionally with ?userID=<user ID> (that person’s grants, including the ones they hold through an access group, which carry viaWorkspaceID and viaWorkspaceName) or ?workspaceID=<access group ID>. Each row also carries featureName, featureScope and, for a feature in the Trash, featureInTrash, and no warnings.

Each listed grant names who holds it (principalName, plus principalEmail for a person — principalKind reads user for a person and workspace for an access group), who granted it and when, active (false is Inactive), and any warnings.

Section titled “Related”