Members

Members and teams

Roles

Every org member has exactly one org-level role.

Role	What they can do
Owner	Full org admin: manage billing, configure SSO and SCIM, manage security policy, invite and remove members, create and delete repositories, access all repository settings, view audit log
Member	Access repositories they have been granted access to; create new repositories (if the org policy permits); no access to org admin settings

An org must have at least one Owner at all times. You cannot remove or demote the last Owner.

Inviting members

Member and team management lives in the Forgejo-native org UI at frem.sh/org/<org>/teams, fremforge admin doesn’t fan-out a separate member tab because Forgejo already owns the identity + team model.

Go to Org → Teams (frem.sh/org/<org>/teams). To grant full org admin rights, open the Owners team; for repo-scoped access, open or create a custom team.
Click Add team member.
Enter the invitee’s username or email address.
Click Add member.

The invitee receives an email from noreply@frem.sh with an accept link. The link is valid for 72 hours (Forgejo-managed). If it expires, resend from the same team page.

In the team member list, the invitee appears as Pending until they accept. Pending members:

Cannot access any org resource.
Do not count as a billable seat until they accept the invitation.
Can be cancelled at any time by removing them from the team while still pending.

Once the invitee accepts, their status changes to Active and they are added to the billable seat count at the next billing cycle. Activity is not required, acceptance is what counts.

Changing roles

Roles in Forgejo are expressed as team membership: Owners = full org admin, any other team = scoped access defined by the team’s repo grants.

Go to Org → Teams (frem.sh/org/<org>/teams).
To promote a Member to Owner: open the Owners team → Add team member.
To demote an Owner: open the Owners team → remove the user. The user retains access via any other teams they’re still on.

Role changes take effect immediately. There is no grace period or confirmation email sent to the member.

Removing a member

Go to Org → Teams (frem.sh/org/<org>/teams).
Open each team the member belongs to (start with Owners if they’re an admin) and remove them. The user is fully off the org once they’re on no team.
Confirm removal in the Forgejo prompt.

What happens immediately:

Access to all org repositories is revoked.
Any active sessions (browser or API) for that user are invalidated.
The member is removed from any team assignments within the org.

What does not change:

Repositories are not deleted. Repos belong to the org, not to individual members. A member who owned repos in the org does not take those repos when they leave.
Issues, PRs, and commits remain attributed to their username. Historical contribution records are preserved.
Open PRs and issues they authored remain open and unmodified.

The removed member is taken out of the billable seat count at the next billing cycle. There is no credit for the current period.

Offboarding checklist

When a member leaves the org, run through this checklist before completing the removal.

Transfer repository ownership if the departing member owns any repos directly (check Org admin → Repositories for repos with their username as owner). Transfer to the org or to another member before removing them.
Rotate secrets they may have known. Check which secrets were created or last updated while they had access. Rotate any that are now exposed by their departure.
Revoke API tokens they created. Go to Org admin → API tokens (/<org>/_admin/api-tokens) to see all org API tokens. Revoke any token created by the departing member.
Check for personal access tokens (PATs). PATs are tied to the user’s account, not the org. Once removed from the org, their PATs can no longer access org resources. But if the departing member was an Owner, confirm no tokens with elevated scopes were shared with external systems under their name.
Review active integrations and webhooks. If any webhook or external integration is authenticating as this user, update it to use an org API token or another account.

SCIM-managed deprovisioning

If SCIM provisioning is configured for the org, user lifecycle is managed by the connected IdP (Okta, Entra ID, etc.). Deactivating or removing a user in the IdP deactivates them in fremforge automatically within the SCIM sync interval, which is typically under five minutes.

When a user is deactivated via SCIM:

Their fremforge session is invalidated immediately.
They cannot sign in via SSO or local password.
Their seat is removed from the billable count at the next billing cycle.

Manual removal via Org → Teams is not required when SCIM is active. The IdP is the source of truth for membership. Removing a user in fremforge without deactivating them in the IdP will cause SCIM to re-provision them on the next sync.

See SCIM provisioning for setup instructions.

SSO-only members

A member who has only ever signed in via SSO has no local fremforge password. Their identity is entirely controlled by the IdP.

To block a SSO-only member’s access:

Revoke their access in the IdP (deactivate the account, remove from the app assignment, or disable SSO for their account).
Optionally remove them from the org in fremforge to clean up the seat count.

Revoking IdP access alone is sufficient to prevent sign-in. The fremforge session will fail at the next SSO validation check. If SCIM is enabled, the IdP deactivation also triggers automatic deprovisioning without the manual org removal step.

Re-inviting a former member

To re-invite someone who was previously removed, add them back to the appropriate team from Org → Teams as normal.

When they rejoin:

Previous commits, issues, and PRs remain attributed to their username.
Repository access is determined freshly by org role and any repo-level collaborator assignments. No previous access configuration is automatically restored.

If the former member deleted their fremforge account after leaving, their username may show as a deleted-account indicator on historical contributions. If a different person has taken that username in the interim, historical attribution reflects the original account via the underlying user ID, not just the username string.

Per-repository permissions

Org-level roles determine baseline access. For finer-grained control, you can add individual users as collaborators on specific repositories.

Add a collaborator:

Go to Repository → Settings → Collaborators.
Search for the user by username or email.
Select a permission level:

Permission	What they can do
Read	Clone, pull, view issues and PRs
Write	Read access plus push branches, create and close issues and PRs
Admin	Write access plus manage repository settings, branch protection, webhooks, and secrets

Collaborator permissions are additive on top of the user’s org role, not a replacement. A Member with Write collaborator access on a repo can push to that repo. An Owner collaborator has no additional effective permissions beyond what the Owner org role already grants.

Collaborators do not need to be org members. You can add external users (with a fremforge account) as collaborators on individual repositories without inviting them to the org. External collaborators count as a billable seat for the org that adds them, same flat €30/seat/month rate, counted on assignment regardless of activity.

Cross-references

SCIM provisioning, automated user lifecycle via Okta, Entra ID, or any SCIM 2.0-compliant IdP
OIDC SSO, configure SSO so members sign in with their corporate identity
Billing, how seats are counted and when removed members leave the billable count
Org admin, full reference for the org admin surface
API, manage members programmatically via the REST API