Your fremforge account

A fremforge account is your personal identity on the platform. An organisation is a billable tenant, a workspace where repositories, members, secrets, CI runs, and policy live. The two are deliberately separate concepts, and this page covers what’s where, how they interact, and how to remove either.

One account, many organisations

You sign up once. You get one personal account at frem.sh/<your-username> with your email, your SSH keys, your personal access tokens, your 2FA, and your local password (if you set one). Anywhere you authenticate against fremforge, UI, Git, API, you authenticate as that account.

Membership in an organisation is a separate relationship. Your one account can be a member of zero, one, or many organisations. Each organisation pays its own seat for you. You see the organisations you belong to in the UI’s org switcher.

Two consequences worth internalising:

• Removing you from an org doesn’t delete your account. Org admins can remove you from their org at any time; that revokes your access to their repos and removes a billable seat from their count, but your personal account remains and you can join other orgs.
• Deleting your account doesn’t delete the organisations you belong to. If you’re the sole owner of an organisation, the platform requires you to either nominate another owner or fully cancel the organisation before your account-deletion request can complete.

Joining a second organisation

You can be the founding admin of more than one fremforge org without creating multiple accounts. Two cases:

• Same email, fresh signup. If you sign up a new org at frem.sh/_app/signup using an email that already has a fremforge account, the signup flow detects the existing user, reuses it, and adds you as Owner of the new org. You don’t get a second password, your existing credentials work for both orgs. The welcome email’s “initial admin password” line is omitted in this case.
• Invited to an existing org. If another admin invites your email, you accept the invite from frem.sh/user/notifications and you’re added as a member of their org. No second account, no second password.

Each org has its own billing relationship with fremverk, its own seat count, its own Mollie mandate, its own invoices, and its own admin surface at frem.sh/_app/<slug>/_admin/billing. There is no consolidated cross-org bill.

Switching between organisations

There’s no in-product org switcher on frem.sh/_app, the per-tenant admin surface is keyed on the slug in the URL path (/<slug>/_admin/...). The natural switcher lives on the Forgejo side at frem.sh:

1. Sign in at frem.sh/user/login (or click “Sign in” anywhere on the marketing site, which routes you through frem.sh/_app/login for email-domain discovery).
2. Your dashboard shows every org you belong to. Click into any one to start working, repos, issues, CI, settings.
3. To open the fremforge admin (billing, SSO, members) for a specific org, navigate to frem.sh/_app/<slug>/_admin/billing. Bookmarking the admin URL per org you administer is the most common pattern.

Per-org session binding records a separate session entry per {user, org} and forces a round-trip through Forgejo authentication the first time your session touches each org’s admin surface. This is on by default for every tenant, the marketing-page promise. After the first round-trip, the per-org session is reused for up to 8 hours.

The round-trip target is Forgejo’s universal login at frem.sh/user/login, not a per-org SSO URL. That’s deliberate: universal login accepts both any wired SSO buttons and local password + 2FA, which preserves the SSO break-glass path, if your IdP is unreachable, an org owner with local credentials and 2FA can still authenticate, satisfy the per-org binding gate, and reach the org admin. Bouncing through a per-org SSO URL would create a single point of failure (the org’s IdP) that the break-glass design exists to avoid.

Two strength tiers depending on your IdP wiring:

• Soft binding (default, local-credentials break-glass preserved): a per-org audit record of who admin’d what when, scoped to the org, and a forced round-trip through Forgejo on first cross-org access. If your Forgejo session is current, the round-trip is invisible (universal login just follows redirect_to); if it isn’t, you sign in again. The bounce target is frem.sh/user/login, which accepts local password + 2FA, so an IdP outage doesn’t lock org owners out.
• Hard binding (regulated workloads): forced IdP re-attestation per org via OIDC prompt=login. The round-trip becomes a real IdP-attested authentication scoped to that org, the IdP MUST re-prompt for credentials and MFA, and our callback verifies auth_time is within the last 5 minutes. Wired by registering a second OIDC client in your IdP next to the Forgejo one (same issuer, separate client_id + client_secret) and pasting the credentials into Org admin → SSO. SAML hard binding (via ForceAuthn="true") is on the roadmap; for now SAML orgs use soft binding.

Both tiers preserve the SSO break-glass path: org owners with local password + 2FA can recover from any IdP outage. Hard binding only forces fresh IdP authentication when your org’s IdP is reachable; if you’ve documented the procedure your owners should follow when it isn’t, that procedure still works.

SSO across multiple orgs

Each org wires its own IdP at Org admin → SSO. Users log in to a specific org via that org’s <auth-source-name> button on frem.sh/user/login?redirect_to=/<slug> (or via the frem.sh/_app/login discovery flow which routes you to the right org’s login page based on your email’s domain).

If you’re a member of two orgs that use different IdPs, you authenticate via whichever IdP you arrive through; once your Forgejo session is established the cross-org navigation works as above. If both orgs use the same IdP (e.g. two business units on the same Authentik tenant), one authentication carries you across both.

First-cross-org access bounces you once. Where the bounce goes depends on whether the org has wired hard binding (a step-up OIDC client):

• Hard-bound org: the bounce goes to frem.sh/_app/<slug>/_admin/-/stepup, which initiates an OIDC AuthN request with prompt=login against the org’s step-up client. Your IdP re-prompts for credentials and MFA, the callback verifies the ID token + auth_time freshness, and you land on the original URL with a fresh per-org session record.
• Soft-bound org: the bounce goes to frem.sh/user/login. Forgejo’s universal login presents whichever auth sources are available, local password + 2FA always, plus your org’s SSO button when wired. If your existing Forgejo session is fresh, the page just follows redirect_to without a re-prompt.

Both tiers leave the local-credential break-glass intact. An org owner with a local password + 2FA on the universal Forgejo login can recover from any IdP outage; the per-org binding doesn’t change that contract.

Account-level vs org-level data

This is the dividing line that decides who controls what under GDPR and where to look for which setting.

Account-level data is governed by the product privacy notice, fremverk ApS is the controller. Org-level content is governed by the Data Processing Agreement, your organisation is the controller, fremverk is the processor on its behalf.

Account settings reference

frem.sh/user/settings is the personal-settings surface. The relevant sub-pages:

• Profile, name, email, avatar, language preference.
• Security, local password, 2FA, recovery codes. See Two-factor authentication.
• SSH / GPG keys, public keys for Git operations and commit signing.
• Applications, personal access tokens (PATs), OAuth applications you’ve authorised.
• Notifications, email and in-app notification preferences.
• Account, email change, account deletion (see below).

Deleting your fremforge account (GDPR right to erasure)

Under GDPR Art. 17 you have the right to have your personal data erased, subject to limited exceptions for legal retention obligations. fremverk ApS supports this right as the controller of your account data.

What you can delete yourself

User settings → Account → Delete account. Self-service deletion:

1. Removes you from every organisation you’re currently a member of. Each affected org’s seat count is reduced at the next billing cycle.
2. Tombstones your username so it cannot be re-registered (this prevents impersonation against historical commits and audit-log entries).
3. Hard-deletes your personal account data: profile, SSH keys, GPG keys, PATs, 2FA secret, recovery code hashes, notification preferences. Within 30 days; backup purge within a further 30 days per DPA §9.
4. Preserves your historical contributions, commit-author attribution, issue and PR authorship, comments, audit-log entries that name you. Removing these would corrupt every organisation that depends on those records as evidence of who did what. Your username is shown as <deleted-account> on the live UI, while the underlying user-id reference (a stable integer) keeps audit and Git history intact.

What requires support

Two cases require action through compliance@frem.sh:

• You’re the sole owner of an organisation. Self-service deletion is blocked. Either nominate another owner via Org admin → Members and then delete your account, or write to compliance@frem.sh requesting org-and-account deletion together.
• You want historical contributions actively rewritten. The default is to preserve attribution under a tombstoned username. If you have a documented legal basis for stronger erasure (a finalised legal name change reflected in court documents, for example), email compliance@frem.sh with the basis. Each request is assessed individually against GDPR Art. 17(3) limitations.

What we don’t delete on request

Per GDPR Art. 17(3), the following may be retained after account deletion:

• Billing and invoice records for organisations you were associated with, retained 5 years per Danish bookkeeping law (Bogføringsloven).
• Security and abuse audit-log entries where retention is necessary for the establishment, exercise, or defence of legal claims, or for compliance with a legal obligation (e.g. DSA Art. 16 abuse reports retained 5 years per Privacy Notice §6).
• Aggregate, anonymised operational metrics, unable to identify you and outside the GDPR scope of personal data.

Verification before deletion

Account deletion is destructive and irreversible. The self-service flow requires re-authenticating (local password, or completing an IdP step-up if you are SSO-only) and confirming by typing your username, the same Forgejo-native pattern used for repository deletion. A confirmation email is sent on submission and again when the backup-purge window completes.

Reactivation

Once deletion completes, the account cannot be reactivated. The username is reserved against the deleted user-id to protect historical attribution, so you cannot re-register the same username from a fresh signup. If you need to use fremforge again, sign up with a new email and a different username.

Cross-references

• Members and teams, managing organisation membership from the org-admin side
• Two-factor authentication, account-level 2FA setup and recovery
• Org admin, the org-level settings surface
• Connecting, SSH host keys, fingerprint verification, port-443 fallback
• Product privacy notice, the legal basis for account-data processing and GDPR data-subject rights