Org admin

The fremforge org admin lives at frem.sh/<your-org>/_admin. A 5-group sidebar holds the admin pages; the topbar carries a Cmd-K (⌘K / Ctrl-K) palette that searches every page by label and keyword. No buried submenus, no surprise modals.

Org, Overview, Repos, Members, SSO, Billing, Public docs, Data export, Settings. Security, Overview, Findings, Components, Prioritise, Fix, Reports, Policies, Access. See Security below. Build & deploy, Environments, Deployments, Secrets, Dependency updates (the same page as Security › Fix), Dependency proxy, frembench. Integration, AI integrations, Programmatic access, Webhooks, SIEM forwarding. Reports, DORA, Audit log (cryptographic integrity in Audit chain), Registry access log, Legal hold, Evidence retention, Legal notices.

If the page you want is on a tenant that’s currently suspended or in the 90-day post-cancellation window, the admin shell is read-only everywhere except Billing and Data export. The banner at the top of every page makes that explicit.

The tab strip is consistent across every admin page; you can switch between tabs without losing your place.

Who can reach the admin

Anyone with Owner role on the Forgejo org. The role is set on Forgejo’s <org>/-/teams/owners page; the cross-check happens server-side on every admin request, so revoking a user’s owner role invalidates their admin session immediately.

Members and outside collaborators can’t reach /admin. The route returns 403 with a “not an org owner” message.

Tabs

Billing

frem.sh/<org>/_admin/billing, covers everything money-related.

• Current seat count + monthly bill estimate
• Payment-method status (with a “Set up payment” link if there’s no mandate yet, or a “Replace payment method” link if the existing mandate is broken)
• Invoice history with downloadable receipts
• Cancel subscription flow (gated by typing the org slug to confirm)

The cancel flow sets cancellation_scheduled with a 30-day window before the cancellation takes effect. During the window the customer can undo from the admin UI or from the email link sent at cancellation time. After the window, the org flips to cancelled (read-only retention for 60 more days), then deleted (purge per DPA §9).

SSO

frem.sh/<org>/_admin/sso, identity federation to your IdP.

• Verified domains, prove you control an email domain via DNS TXT or .well-known HTTP file. Required before any Auth Source that uses the domain is activated.
• Auth sources, register OIDC providers.

Once verified + registered, your users sign in with their IdP at frem.sh/<org>/login. PATs and SSH keys remain valid in their own right; when Require SSO is enabled, fremforge revalidates the IdP session every 15 minutes on Git operations, so a user deactivated in the IdP loses Git access within that window even if their key is still on the account. See OIDC SSO for the full enforcement model.

See migration → GitHub → Step 7: Verify and decommission for SSO sign-in verification as part of a full migration, or follow the Auth Source setup steps directly in the SSO tab described above.

Security

frem.sh/<org>/_admin/security/overview. The Security group of the sidebar has eight entries, in the order you work through a finding: detect, prioritise, fix, report, plus the policies that decide what is allowed and who gets in.

Every older address of these pages, such as _admin/security/policies/edge, _admin/code-security/…, _admin/compliance-evidence or _admin/attestations, redirects to its new tab. “Edge policies” no longer exists: its settings are on Prioritise (Fix-by SLA, Pull request checks), Access (IP allowlist, Support access, AI connectors, and the two-factor information on Authentication policy) and Reports › Notifications (the security digest).

Push protection

frem.sh/<org>/_admin/security/policies/push-protection. Secret scanning on every push is always on. This tab holds the override list and the scanner failure mode.

• Recent rejections, every push that was blocked because gitleaks matched a high-confidence secret pattern. Click “Approve” to convert into a one-shot or pattern-scoped override.
• Active overrides, your allow-list. Each override carries a reason (audit-logged) and optional rule / path-pattern / commit / repo scoping. Revoke any override at any time.

If a finding is a real secret, rotate it at the issuing service first, then git filter-repo to remove it from history, then push. If it’s a false positive (test fixture, intentional public credential), add a path-scoped override. See Push protection.

Findings

frem.sh/<org>/_admin/security/findings/sast. One tab per scanner: SAST, Dependencies, Licences, Container images, Secret scanning, Malware (the upload malware scan), plus Exceptions. Each tab shows its findings first, with one line saying whether the scanner is on and at which severity its pull request check fails. The settings themselves are on Security › Policies › Scanners. The rules a finding is judged by, such as the licence lists and the image pull gate, are under Security › Policies (see Security policies).

Dependency updates

frem.sh/<org>/_admin/dependency-updates, under Security › Fix (Build & deploy keeps a link to the same page). One page with two lanes: Security fixes, one pull request per vulnerable package driven by your findings, and Version updates by hosted Renovate. It also lists the repositories that take part and the recent activity.

• Enable, provisions a per-tenant bot user and starts a nightly run for the organisation’s repositories.
• Recent runs, last 10 Renovate runs with PR counts and any errors.
• Run now, out-of-cycle trigger (rate-limited 1/h).
• Disable, revokes the bot’s token immediately and removes it from the org. PRs already opened by the bot stay open.

Per-repo configuration is via renovate.json in the repo root. See Dependency updates for both lanes, Version updates for the Renovate reference, and Security fixes for fix pull requests driven by findings.

Secrets

frem.sh/<org>/_admin/secrets, org-level Actions secrets injected into every CI job in the org as environment variables. Forgejo is the storage layer (encrypted at rest); fremforge admin proxies the CRUD operations and emits audit events scoped to the secret name + actor + timestamp (the value is never persisted in fremforge’s database or audit log).

• New / overwrite secret, name (UPPER_SNAKE_CASE; cannot start with FORGEJO_ or GITHUB_) and value. Submitting an existing name overwrites; the same form is the rotation flow.
• Active secrets, list of names + created-at timestamp. Values are write-only, fremforge never reads or echoes a value back after creation.
• Delete, typed-confirm via JS confirm() prompt. Workflows referencing the secret will fail until it is recreated.

Org secrets are inherited by every repository in the org. For per-repo or per-environment scope, set the secret at Repository → Settings → Secrets or Repository → Settings → Environments → <env> → Secrets, those scopes live in Forgejo native UI, not fremforge admin (per-repo / per-environment secrets are out-of-scope at the org level by design). The most specific scope wins; an environment secret with the same name as an org secret shadows the org secret for jobs in that environment.

See Secrets for the full reference including the API path and rotation procedure.

Repo defaults

frem.sh/<org>/_admin/repo-defaults redirects to Security › Policies › Repository rules (_admin/security/policies/repository-rules#org-baseline): the branch-protection defaults for the organisation’s repositories, such as required approvals, CODEOWNERS review and signed commits. See Branch protection.

Webhooks

frem.sh/<org>/_admin/webhooks, webhook delivery history and redelivery for events fanned-out across the org. Webhook creation (which events to subscribe to, target URL, signing secret) is configured in Forgejo native UI at /<org>/-/settings/hooks (org-level) or /<org>/<repo>/settings/hooks (repo-level). fremforge owns the delivery-history dashboard at admin → Webhooks; Forgejo owns registration.

• Recent deliveries, inspect individual delivery attempts, response codes, and payloads.
• Redeliver, re-fire any event from the history view. Useful for debugging receiver-side bugs after a fix.

Org webhooks fire for the same event shape as per-repo webhooks. See webhooks for the full event type reference and payload schema.

Environments

frem.sh/<org>/_admin/environments, GitHub-style deployment environments for CI/CD jobs. Each environment carries a name (referenced from workflow YAML as jobs.<id>.environment: <name>), branch/tag protection patterns, scoped secrets, and scoped variables.

• Deployment branches and tags, glob patterns (main, release/*, v[0-9]*) that restrict which refs can deploy to this environment. Refs that don’t match are refused before the runner even pulls the workflow.
• Environment secrets, encrypted secrets injected into jobs running with environment: <name>. Shadow org-level secrets with the same key. Useful for prod-only credentials.
• Environment variables, non-secret env vars (region, deployment URL, etc.) bound to the environment.
• OIDC federation, every workflow run carries an OIDC token whose sub claim embeds the environment name (repo:owner/repo:environment:prod). Trust this in your cloud’s IdP to grant short-lived deployment credentials without long-lived secrets.

See deploy secrets for the full OIDC federation walkthrough including AWS, Azure, GCP, and T Cloud Public trust policies.

Build artifact retention

frem.sh/<org>/_admin/artifact-retention, the organisation’s retention setting for Forgejo Actions artifacts (build outputs, test reports, debug bundles), in days from 1 to 90. The default is 30 days for new organisations, and organisations that never changed it moved from 90 to 30 on 2026-10-21. A value you set yourself is kept.

What actually deletes an artifact today. Forgejo expires an artifact after the retention-days given when it was uploaded, or after the platform ceiling of 90 days (the Forgejo instance’s [actions].ARTIFACT_RETENTION_DAYS), whichever is shorter. The organisation setting above does not yet delete anything: the nightly job meant to apply a shorter value needs an artifact API that this Forgejo version does not have. To keep artifacts for less than 90 days, set retention-days on the upload:

- uses: actions/upload-artifact@v3
  with:
    name: test-report
    path: report/
    retention-days: 7

Expired artifacts stop counting against the organisation’s artifact quota.

SIEM forwarding

frem.sh/<org>/_admin/siem, stream the tenant audit log to your SIEM in near-real-time. Supports Splunk HEC, Sentinel HTTP Data Collector, Elastic Cloud, and generic webhook with HMAC-SHA256 signing. Splunk and Sentinel require a thin HMAC-translation proxy (see SIEM forwarding); Elastic Filebeat and generic webhook are direct. Each endpoint can be tested with a synthetic event before going live; bad endpoints back-off and surface failures in the operator portal.

Vendor attestation and control evidence

Both are under Security › Reports: Vendor attestation (_admin/security/reports/vendor-attestation) is a document about fremforge as your vendor, and Control evidence (_admin/security/reports/control-evidence) maps your organisation’s audit events to SOC 2 and ISO 27001 controls. SLSA build provenance is under Security › Components › Build attestations; see SLSA provenance.

Org and repository lifecycle

A few operations sit outside the tab grid because they are one-off rather than ongoing configuration. They live in their natural home (the repo settings page, or the org-rename page), but they’re worth pointing at here so they’re not invisible.

Renaming an organisation

frem.sh/<org>/_admin/settings, change the org slug. Existing repository URLs, clone URLs, API calls, and webhook payload references using the old slug continue to redirect for 90 days after the rename. After 90 days the old slug becomes available for registration again, so plan the cutover, update integrations during the redirect window, and don’t sit on it.

The rename is an org owner action, audit-logged, and confirmed by typing the old slug.

Transferring a repository to another org

frem.sh/<org>/<repo>/settings → Transfer ownership. A repo can be transferred to another org you own (or to another user’s account; they must accept). On transfer:

• All branches, tags, history, issues, PRs, releases, packages, webhooks, and CI workflow runs move with the repo.
• Forks of the repo on fremforge stay where they were, they update their upstream pointer to the new location automatically.
• Outstanding git clone, git fetch, and HTTP API URLs against the old <org>/<repo> path redirect for 90 days, the same window as an org rename. Update remotes opportunistically; the redirect is operational headroom, not a permanent guarantee.

Transfer is gated by the destination org’s policy: if the destination org enforces SSO / signed commits / etc., the transferred repo inherits that policy on arrival; existing branch-protection rules on the repo are preserved unless the destination org’s defaults are stricter.

Cancelling a subscription

Owner action, gated by typing the org slug. See the Billing tab above for the cancellation flow and the Billing page for the lifecycle states (cancellation scheduled → cancelled → deleted).

Deleting a personal account

Out of scope for the org-admin surface. Personal account deletion (GDPR right of erasure) lives at User settings → Account. See Your fremforge account for the full flow including what’s preserved as historical attribution.

Branch protection, concept reference

Branch protection follows a three-tier hierarchy: platform floor (set by fremforge, not configurable) → org default (set by org owner, applies to all repositories) → per-repository rules (can tighten org defaults, cannot loosen below the org floor).

Org default protection: Security › Policies › Repository rules, branch protection defaults. Set rules that apply to all newly created repositories and all existing repositories where no stricter repo-level override exists.

Per-repository protection: Repository → Settings → Branches → Add rule. Enter a branch name pattern (e.g., main, release/*). Available protections:

Platform floor: The platform enforces: signed commits are allowed (not forced) at the platform level; secret scanning runs regardless of branch protection settings; the audit log records all force-push events even if force-push is not blocked.

Policy inheritance: If the org default requires 1 PR review and a repository rule requires 2, the stricter rule (2) wins. Repository rules can only tighten, not loosen.

Data export

frem.sh/<org>/_admin/data-export, full self-service export.

• Start a new export, assembles a single signed .tar.gz with a git bundle per repo, each repo’s issues, pull requests, comments, labels, milestones and releases, the package inventory and a 90-day audit slice. See Data export for exactly what is in it.
• Recent jobs, last 20 export jobs with download links (valid 7 days after ready) and status.

Rate-limited to one export per org per 24 hours. Bundles >50 GB use a different procedure. Contact support.

See data-export for the bundle layout, verification recipes, and the API endpoints.

Settings

frem.sh/<org>/_admin/settings, core org metadata: visibility (public / limited / private), display name, description, website, location. Changes here are proxied to Forgejo via PATCH /api/v1/orgs/{org} and emit an tenant.org.settings.updated audit event.

Settings handled elsewhere:

• Org name (slug), renaming the slug is a Forgejo action with a 90-day redirect window; manage it in Forgejo native UI under /<org>/-/settings.
• Avatar / profile image, Forgejo native UI under /<org>/-/settings.
• Billing, SSO, security policy, push protection, see the dedicated tabs above.

The boundary: fremforge admin owns org name (display), visibility, website, description, location alongside the dedicated subscription / policy / security / audit tabs. Forgejo native UI at /<org>/-/settings owns avatar / profile image, slug rename, repo-creation defaults internal to Forgejo, deeper Forgejo-only configuration. Both are reachable from owner accounts; pick whichever surface fits the change you’re making.

Audit log

frem.sh/<org>/_admin/audit-log, every state-changing admin action against your org, browsable in real time.

• Actor filter, narrow to a specific Forgejo user, or to operator actions (prefixed operator:<email>).
• Action filter, narrow to a namespace (e.g. push-protection or billing.cancel).
• Since filter, date-bounded.
• Operator badge, fremverk staff actions taken on your org’s behalf are highlighted in orange and never silent. The same data lands in the audit slice of your data-export bundle.

Older events truncate after 200 rows on the screen. For full historical pulls, use Data export. The audit-log slice in the bundle is unbounded.

Retention. Per DPA Annex A.7, security-relevant events (authentication, authorisation, admin actions) live in a queryable hot tier with a per-tenant retention you set under Security → Authentication policy → Audit log retention: presets are 90 / 180 / 365 / 730 days, defaulting to 90 (standard plan) or 365 (enterprise plans). Operational logs (HTTP, runner, infrastructure) are kept hot for 30 days (not configurable). Both tiers are written to an immutable WORM archive on T Cloud Public OBS for 3 years, with hash-chain anchoring every 2 minutes for tamper evidence — after the hot-tier cutoff the payload (actor, fields_json) is redacted, but the SHA-256 chain hashes are retained for the full 3 years. The on-screen view and the data-export bundle’s audit slice both cover the configured hot-tier window. To pull older events from the WORM archive, contact support@frem.sh.

API equivalence

Every admin action is also a documented REST endpoint. The admin UI is itself a client of the same API an AI agent would consume. See public REST API for the OpenAPI spec.

Two namespaces, one base host. Routes under /api/v1/... are Forgejo-native (same shape as the upstream Forgejo API, no fremforge prefix — used for org/repo/user/issue/PR CRUD that Forgejo already covers). Routes under /_app/api/v1/... are fremforge-extension (the control-plane additions we layer on top — billing, push-protection, data-export, hosted-Renovate, SSO policy, attestations). The PATCH /api/v1/orgs/{org} call referenced by §Settings above is the Forgejo-native form; the same network host serves both prefixes via platform routing. Pick the prefix that matches the documented endpoint and don’t mix.

This means anything you do in the admin UI you can also do programmatically:

• POST /_app/api/v1/orgs/<org>/dependency-updates/enrol, same as clicking “Enable hosted Renovate” (fremforge-extension)
• POST /_app/api/v1/orgs/<org>/exports, same as clicking “Start a new export” (fremforge-extension)
• GET /_app/api/v1/orgs/<org>/push-protection/overrides, list active push-protection overrides (fremforge-extension)
• PATCH /api/v1/orgs/<org>, update display name / website / location / visibility (Forgejo-native)
• …etc.

Token authentication: PAT issued from your Forgejo user settings. OAuth 2.0 client-credentials is planned alongside the agent-identity flow.

Audit trail

Every admin action emits a structured log line to fremforge’s audit stream with fields: actor, action, tenant_id, plus action-specific fields. The audit log is included in the data export bundle scoped to your org.

What you see in your audit slice:

• All POST/DELETE actions on the admin UI (any state-changing thing)
• All API calls authenticated as a member of your org
• All operator actions taken on your org’s behalf by fremverk staff (these are flagged with actor=operator:<email>, never silent)

What you don’t see (privacy and legal-process reasons):

• fremverk-internal infrastructure events (those go to a separate audit stream)
• Cross-tenant correlation identifiers (redacted before export)

Cross-references

• Pricing, what’s included in the €30/seat plan
• Trust, sub-processors, certifications, sovereignty posture
• Public REST API, programmatic equivalents of every admin action
• Migration guides, step-by-step setup from GitHub / GitLab / Azure DevOps