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, Setup, Settings, SSO, Billing. Security, Policies, Push protection, SAST findings, Dependencies, Licenses, Container images, SBOMs, Build attestations, Malware scan, Compliance evidence. Build & deploy, Environments, Secrets, Repo defaults, Runner OIDC, Dependency updates, Repo mirroring. Integration, API tokens, Webhooks, SIEM forwarding. Reports, DORA, Audit log (cryptographic integrity in Audit chain), Compliance attestations, Data export.

If the page you want is on a tenant that’s currently suspended or in the 60-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 and SAML 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 & policies

frem.sh/<org>/_admin/security/policies, org-wide security controls and notification preferences.

• 2FA enforcement, require all org members to have two-factor authentication enabled. Members who haven’t enrolled are prompted to set up 2FA on next login; until they do, they cannot access org resources. Owners are exempt from the enforcement lock-out (they need a way in to fix misconfiguration), but the setting is logged.
• IP allowlist, restrict org access to specific CIDR ranges. Any request originating outside the allowlist is denied at the org boundary (the Forgejo session layer), regardless of valid credentials or SSO status. Add named entries (e.g. “Office VPN”, “CI egress”) for auditability.
• Notification preferences, configure which security events trigger email or webhook notifications at the org level (e.g. push-protection rejections, new CVE PRs from Renovate, SAST finding summaries).

Push protection

frem.sh/<org>/_admin/push-protection, secret scanning is on by default for every fremforge org. This tab is for managing the override list.

• 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.

The default policy is block on high-confidence findings, no override unless documented. 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.

Code security

frem.sh/<org>/_admin/code-security, the supply-chain trio in one place. Three sub-tabs:

• SAST findings, OpenGrep results posted as PR comments at scan time, listed here for org-level review. Settings include severity floor (block-on-error vs. block-on-warning) and an optional custom-rules URL.
• SBOMs, Software Bill of Materials emitted by every release build, in both SPDX 2.3 and CycloneDX 1.5 formats. Download via the admin UI or via the public REST API at /_app/api/v1/repos/.../releases/.../sbom?format=spdx|cyclonedx. EU CRA Annex I forcing function from late 2026.
• Container images, Trivy scans every image pushed to your fremforge package registry. Settings include the block-pull policy on critical findings (none / warn / block_pull).

All three pair with push protection (push-time secret detection) and dependency updates (scheduled CVE patching) to complete the OWASP / NIS2 Art. 21 / CRA Annex I supply-chain story.

Dependency updates

frem.sh/<org>/_admin/dependency-updates, hosted Renovate.

• Enable, provisions a per-tenant bot user (e.g. <org>-renovate-bot) and starts the monthly + weekly-security cadence.
• 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. The full config schema is at docs.renovatebot.com; fremforge runs the upstream Renovate image unmodified, so every config option works.

See dependency-updates for the full feature reference.

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, org-level policies applied when new repositories are created. Existing repos keep their per-repo configuration; this policy doesn’t backfill.

• Branch protection, required approving reviewers, dismiss stale reviews on push, require all status checks, require linear history, require signed commits (SSH-key or GPG), comma-separated protected-branch glob patterns.
• Force-push block on protected branches, platform floor; can’t be disabled. Force-push to a protected branch is a destructive operation that the platform refuses across all orgs.

To bring an existing repo into line with the org default, use the repo’s own Settings → Branches page on Forgejo.

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 trust policies.

Build artifact retention

frem.sh/<org>/_admin/artifact-retention, set how long Forgejo Actions artifacts (build outputs, test reports, debug bundles) are kept before deletion. The platform ceiling is 90 days (the Forgejo instance’s [actions].ARTIFACT_RETENTION_DAYS); customers can shorten it to save storage, not raise it. A nightly job sweeps artifacts past the retention window across every repo, shortening is destructive and irreversible at the next sweep, so review before applying.

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. Each endpoint can be tested with a synthetic event before going live; bad endpoints back-off and surface failures in the operator portal.

Attestations

frem.sh/<org>/_admin/attestations, read-only inventory of supply-chain attestations (in-toto, SLSA provenance, SBOM signatures) emitted by your workflows. Verifies signatures against the runner’s OIDC issuer at view time. The same attestations are reachable from each release via /_app/api/v1/repos/.../releases/.../attestations.

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: Org admin → Repo defaults → Branch protection. 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 zip with tenant metadata + invoices + repo git bundle files + LFS manifests + Actions logs + audit slice + SLSA attestations.
• 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 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 Bunny 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>/data-export/full, same as clicking “Start a new export” (fremforge-extension)
• GET /api/v1/orgs/<org>/push-protection/overrides, list active push-protection overrides (Forgejo-native)
• 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 lands in Phase 2 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