Organisationsadministration

Oversat fra den engelske original. Hvis de to versioner er forskellige, gælder den engelske. Oversættelsen er endnu ikke korrekturlæst af en dansk modersmålsbruger.

Administrationen af din fremforge-organisation ligger på frem.sh/<your-org>/_admin. En sidebjælke med fem grupper samler administrationssiderne, og topbjælken har en Cmd-K-palet (⌘K / Ctrl-K), der søger på tværs af alle sider efter navn og nøgleord. Ingen skjulte undermenuer og ingen overraskende dialogbokse.

Organisation: Opsætning, Indstillinger, SSO, Fakturering. Sikkerhed: Politikker, Push-beskyttelse, SAST-fund, Afhængigheder, Licenser, Container-images, SBOM’er, Build-attestationer, Malwarescanning, Compliance-dokumentation. Byg og udrul: Miljøer, Secrets, Standarder for repositories, Runner-OIDC, Opdateringer af afhængigheder, Spejling af repositories. Integration: API-tokens, Webhooks, SIEM-videresendelse. Rapporter: DORA, Revisionslog (kryptografisk integritet i Audit chain), Compliance-attestationer, Dataeksport.

Hvis den side, du skal bruge, hører til en organisation, der lige nu er suspenderet eller befinder sig i 90-dages-perioden efter opsigelse, er administrationen skrivebeskyttet overalt undtagen Fakturering og Dataeksport. Banneret øverst på hver side gør det tydeligt.

Fanerækken er den samme på alle administrationssider, så du kan skifte mellem faner uden at miste din plads.

Hvem har adgang til administrationen

Alle med rollen Owner i Forgejo-organisationen. Rollen sættes på Forgejos side <org>/-/teams/owners. Rollen kontrolleres på serveren ved hver forespørgsel til administrationen, så når du fjerner en brugers ejerrolle, bliver brugerens administrationssession ugyldig med det samme.

Medlemmer og eksterne samarbejdspartnere har ikke adgang til /admin. Ruten svarer 403 med beskeden “not an org owner”.

Faner

Fakturering

frem.sh/<org>/_admin/billing dækker alt, der har med penge at gøre.

• Nuværende antal pladser og et overslag over den månedlige regning
• Status for betalingsmetode (med et link til at sætte betaling op, hvis der endnu ikke er et mandat, eller til at erstatte betalingsmetoden, hvis det eksisterende mandat ikke virker)
• Fakturahistorik med kvitteringer, du kan downloade
• Opsigelse af abonnementet (du bekræfter ved at skrive organisationens slug)

Opsigelsen sætter cancellation_scheduled med en frist på 30 dage, før opsigelsen træder i kraft. I den periode kan kunden fortryde i administrationen eller via linket i den e-mail, der sendes ved opsigelsen. Når fristen er udløbet, skifter organisationen til cancelled (skrivebeskyttet opbevaring i yderligere 60 dage) og derefter til deleted (sletning efter DPA §9).

SSO

frem.sh/<org>/_admin/sso: føderering af identitet til din identitetsudbyder (IdP).

• Verificerede domæner: bevis, at du kontrollerer et e-maildomæne, via en DNS TXT-post eller en .well-known-fil over HTTP. Det skal være på plads, før en autentificeringskilde, der bruger domænet, kan aktiveres.
• Autentificeringskilder: registrér OIDC- og SAML-udbydere.

Når domænet er verificeret og udbyderen registreret, logger brugerne ind med deres IdP på frem.sh/<org>/login. PAT’er og SSH-nøgler er fortsat gyldige i sig selv. Når Require SSO er slået til, genvaliderer fremforge IdP-sessionen hvert 15. minut ved Git-operationer, så en bruger, der deaktiveres i IdP’en, mister Git-adgangen inden for det tidsrum, selv om nøglen stadig ligger på kontoen. Se OIDC SSO for hele håndhævelsesmodellen.

Se migrering → GitHub → Step 7: Verify and decommission for, hvordan du verificerer SSO-login som en del af en fuld migrering, eller følg opsætningstrinnene for autentificeringskilder direkte under SSO-fanen beskrevet ovenfor.

Sikkerhed og politikker

frem.sh/<org>/_admin/security/policies: sikkerhedskontroller og notifikationsindstillinger for hele organisationen.

• Krav om 2FA: kræv, at alle medlemmer af organisationen har tofaktorgodkendelse slået til. Medlemmer, der ikke har tilmeldt sig, bliver bedt om at sætte 2FA op ved næste login, og indtil de gør det, har de ikke adgang til organisationens ressourcer. Ejere er undtaget fra udelukkelsen (de skal kunne komme ind og rette en fejlkonfiguration), men indstillingen logges.
• IP-tilladelsesliste: én liste over tilladte CIDR-intervaller for alle organisationens HTTPS-overflader: webadministrationen, fremforge-API’et, repositoriernes webgrænseflade, Forgejos REST API, Git over HTTPS, Git LFS og pakke-registries. Forespørgsler uden for listen afvises, også med gyldige legitimationsoplysninger. Git over SSH er ikke omfattet. Se IP-tilladelsesliste.
• Notifikationsindstillinger: vælg, hvilke sikkerhedshændelser der udløser notifikationer via e-mail eller webhook på organisationsniveau (fx afvisninger fra push-beskyttelse, nye CVE-pull requests fra Renovate og opsummeringer af SAST-fund).

Push-beskyttelse

frem.sh/<org>/_admin/push-protection: scanning for secrets er slået til som standard for alle fremforge-organisationer. Denne fane bruges til at administrere listen over undtagelser.

• Seneste afvisninger: alle push, der blev blokeret, fordi gitleaks genkendte et secret-mønster med høj sikkerhed. Klik på “Approve” for at gøre afvisningen til en engangsundtagelse eller en undtagelse afgrænset til et mønster.
• Aktive undtagelser: din allowlist. Hver undtagelse har en begrundelse (logges i revisionsloggen) og kan valgfrit afgrænses til regel, stimønster, commit eller repository. Du kan til enhver tid tilbagekalde en undtagelse.

Standardpolitikken er bloker ved fund med høj sikkerhed, ingen undtagelse uden dokumentation. Er fundet et rigtigt secret, så rotér det først hos den tjeneste, der har udstedt det, fjern det derefter fra historikken med git filter-repo, og push så. Er det en falsk positiv (en testfixture eller bevidst offentlige legitimationsoplysninger), så tilføj en undtagelse afgrænset til stien.

Kodesikkerhed

frem.sh/<org>/_admin/code-security: forsyningskædens tre værktøjer samlet ét sted. Tre underfaner:

• SAST-fund: OpenGrep-resultater, der postes som kommentarer på pull requests ved scanningen, og som listes her til gennemgang på organisationsniveau. Indstillingerne omfatter en minimumsgrad (bloker ved fejl eller bloker ved advarsel) og en valgfri URL til egne regler.
• SBOM’er: Software Bill of Materials, der dannes ved hvert release-build, i både SPDX 2.3- og CycloneDX 1.6-format. Download via administrationen eller via det offentlige REST API på /api/v1/repos/.../releases/.../sbom?format=spdx|cyclonedx. EU’s CRA bilag I gør dem påkrævet fra sidst i 2026.
• Container-images: Trivy scanner hvert image, der pushes til dit fremforge-pakke-registry. Indstillingerne omfatter politikken for at blokere pull ved kritiske fund (none / warn / block_pull).

Alle tre spiller sammen med push-beskyttelse (opdagelse af secrets ved push) og opdateringer af afhængigheder (planlagt lukning af CVE’er) og dækker dermed forsyningskæden efter OWASP, NIS2 art. 21 og CRA bilag I.

Opdateringer af afhængigheder

frem.sh/<org>/_admin/dependency-updates: hostet Renovate.

• Aktivér: opretter en botbruger for organisationen (fx <org>-renovate-bot) og starter den ugentlige kørsel på den ugedag, din organisation er tildelt. Sikkerhedsopdateringer oprettes, så snart en advisory dukker op.
• Seneste kørsler: de sidste 10 Renovate-kørsler med antal pull requests og eventuelle fejl.
• Kør nu: start en kørsel uden for den faste plan (højst 1 pr. time).
• Deaktivér: tilbagekalder straks bottens token og fjerner den fra organisationen. Pull requests, som botten allerede har oprettet, forbliver åbne.

Konfiguration pr. repository sker i renovate.json i roden af repositoryet. Det fulde konfigurationsskema finder du på docs.renovatebot.com. fremforge kører upstream-imaget af Renovate uændret, så alle konfigurationsmuligheder virker. Regler i repositoryet anvendes efter platformspolitikken og kan tilsidesætte den. Se Platform policy.

Se opdateringer af afhængigheder for den fulde funktionsbeskrivelse.

Secrets

frem.sh/<org>/_admin/secrets: Actions-secrets på organisationsniveau, som injiceres som miljøvariabler i alle CI-job i organisationen. Forgejo er lagringslaget (krypteret i hvile). fremforge-administrationen videresender oprettelse, opdatering og sletning og udsender revisionshændelser med secretets navn, aktør og tidsstempel (selve værdien gemmes aldrig i fremforges database eller revisionslog).

• Nyt eller overskriv secret: navn (UPPER_SNAKE_CASE, må ikke starte med FORGEJO_ eller GITHUB_) og værdi. Indsender du et navn, der allerede findes, overskrives det. Den samme formular bruges til rotation.
• Aktive secrets: liste over navne og oprettelsestidspunkt. Værdier kan kun skrives: fremforge læser eller viser aldrig en værdi igen, når den er oprettet.
• Slet: bekræftes via en JS confirm()-dialog. Workflows, der refererer til secretet, fejler, indtil det oprettes igen.

Organisationens secrets arves af alle repositories i organisationen. Skal et secret gælde for ét repository eller ét miljø, sætter du det under Repository → Settings → Secrets eller Repository → Settings → Environments → <env> → Secrets. De niveauer ligger i Forgejos egen brugerflade, ikke i fremforge-administrationen (secrets pr. repository og pr. miljø hører bevidst ikke til organisationsniveauet). Det mest specifikke niveau vinder: et miljø-secret med samme navn som et organisations-secret skygger for organisations-secretet i job, der kører i det miljø.

Se Secrets for den fulde reference, herunder API-stien og fremgangsmåden ved rotation.

Standarder for repositories

frem.sh/<org>/_admin/repo-defaults: politikker på organisationsniveau, der anvendes, når nye repositories oprettes. Eksisterende repositories beholder deres egen konfiguration; politikken bliver ikke anvendt bagudrettet.

• Branch protection: antal godkendende reviewers, afvisning af forældede reviews ved push, krav om at alle statustjek består, krav om lineær historik, krav om signerede commits (SSH-nøgle eller GPG) samt kommaseparerede glob-mønstre for beskyttede branches.
• Blokering af force-push på beskyttede branches: platformens minimum, som ikke kan slås fra. Force-push til en beskyttet branch er en destruktiv handling, som platformen afviser i alle organisationer.

Vil du bringe et eksisterende repository i overensstemmelse med organisationens standard, så brug repositoryets egen side Settings → Branches i Forgejo.

Webhooks

frem.sh/<org>/_admin/webhooks: leveringshistorik og genlevering af webhooks for hændelser på tværs af organisationen. Oprettelse af webhooks (hvilke hændelser der abonneres på, mål-URL og signeringssecret) konfigureres i Forgejos egen brugerflade på /<org>/-/settings/hooks (organisationsniveau) eller /<org>/<repo>/settings/hooks (repositoryniveau). fremforge står for dashboardet med leveringshistorik under admin → Webhooks; Forgejo står for registreringen.

• Seneste leveringer: se de enkelte leveringsforsøg, svarkoder og payloads.
• Genlevér: send en hvilken som helst hændelse igen fra historikken. Nyttigt, når du skal fejlfinde hos modtageren efter en rettelse.

Organisationens webhooks sendes med samme hændelsesformat som webhooks på repositoryniveau. Se webhooks for den fulde oversigt over hændelsestyper og payload-skemaet.

Miljøer

frem.sh/<org>/_admin/environments: deployment-miljøer i GitHub-stil til CI/CD-job. Hvert miljø har et navn (som workflow-YAML refererer til med jobs.<id>.environment: <name>), beskyttelsesmønstre for branches og tags, egne secrets og egne variabler.

• Branches og tags til deployment: glob-mønstre (main, release/*, v[0-9]*), der begrænser, hvilke refs der må deploye til miljøet. Refs, der ikke matcher, afvises, før runneren overhovedet henter workflowet.
• Miljø-secrets: krypterede secrets, der injiceres i job, som kører med environment: <name>. De skygger for organisations-secrets med samme nøgle. Nyttigt til legitimationsoplysninger, der kun må bruges i produktion.
• Miljøvariabler: ikke-hemmelige miljøvariabler (region, deployment-URL osv.), der hører til miljøet.
• OIDC-føderering: hver workflow-kørsel har et OIDC-token, hvis sub-claim indeholder miljøets navn (repo:owner/repo:environment:prod). Lad din clouds IdP stole på det, så den kan udstede kortlivede legitimationsoplysninger til deployment uden langlivede secrets.

Se deploy-secrets for hele gennemgangen af OIDC-føderering, herunder trust policies for AWS, Azure, GCP og T Cloud Public.

Opbevaring af build-artefakter

frem.sh/<org>/_admin/artifact-retention: bestem, hvor længe artefakter fra Forgejo Actions (build-output, testrapporter, debug-bundter) gemmes, før de slettes. Platformens loft er 90 dage (Forgejo-instansens [actions].ARTIFACT_RETENTION_DAYS). Du kan sætte perioden ned for at spare lagerplads, men ikke op. Et natligt job fjerner artefakter, der er ældre end opbevaringsperioden, i alle repositories. Det er destruktivt og uigenkaldeligt at forkorte perioden, når næste oprydning har kørt, så tjek grundigt, før du gemmer.

SIEM-videresendelse

frem.sh/<org>/_admin/siem: send organisationens revisionslog til din SIEM i næsten realtid. Understøtter Splunk HEC, Sentinel HTTP Data Collector, Elastic Cloud og en generisk webhook med HMAC-SHA256-signering. Splunk og Sentinel kræver en tynd proxy, der oversætter HMAC (se SIEM-videresendelse); Elastic Filebeat og den generiske webhook virker direkte. Hvert endpoint kan testes med en syntetisk hændelse, før det sættes i drift. Endpoints, der fejler, får forsinket genforsøg, og fejlene vises i operatørportalen.

Attestationer

frem.sh/<org>/_admin/attestations: skrivebeskyttet oversigt over attestationer for forsyningskæden (in-toto, SLSA provenance, SBOM-signaturer), som dine workflows udsender. Signaturerne verificeres mod runnerens OIDC-udsteder, når du ser dem. De samme attestationer kan hentes fra hver release via /api/v1/repos/.../releases/.../attestations.

Livscyklus for organisationer og repositories

Nogle få handlinger ligger uden for fanerne, fordi de er engangshandlinger og ikke løbende konfiguration. De ligger det naturlige sted (repositoryets indstillinger eller siden til omdøbning af organisationen), men de nævnes her, så de ikke bliver overset.

Omdøb en organisation

frem.sh/<org>/_admin/settings: skift organisationens slug. Eksisterende repository-URL’er, clone-URL’er, API-kald og referencer i webhook-payloads, der bruger det gamle slug, bliver fortsat omdirigeret i 90 dage efter omdøbningen. Efter 90 dage kan det gamle slug registreres igen af andre, så planlæg skiftet, opdatér integrationerne i omdirigeringsperioden, og lad være med at vente.

Omdøbning er en handling for organisationens ejere, den logges i revisionsloggen, og den bekræftes ved at skrive det gamle slug.

Overfør et repository til en anden organisation

frem.sh/<org>/<repo>/settings → Transfer ownership. Et repository kan overføres til en anden organisation, du ejer (eller til en anden brugers konto, som så skal acceptere). Ved overførslen:

• Alle branches, tags, historik, issues, pull requests, releases, pakker, webhooks og CI-workflow-kørsler flytter med repositoryet.
• Forks af repositoryet på fremforge bliver, hvor de er, og deres upstream-henvisning opdateres automatisk til den nye placering.
• Eksisterende git clone-, git fetch- og HTTP API-URL’er mod den gamle sti <org>/<repo> omdirigeres i 90 dage, samme periode som ved omdøbning af en organisation. Opdatér remotes, når det passer dig; omdirigeringen er en driftsmæssig buffer, ikke en permanent garanti.

Overførslen er underlagt den modtagende organisations politik: håndhæver den SSO, signerede commits osv., arver det overførte repository den politik ved ankomsten. Eksisterende branch protection-regler på repositoryet bevares, medmindre den modtagende organisations standarder er strengere.

Opsig et abonnement

En handling for ejere, som bekræftes ved at skrive organisationens slug. Se fanen Fakturering ovenfor for forløbet ved opsigelse og siden Billing for livscyklussens tilstande (opsigelse planlagt → opsagt → slettet).

Slet en personlig konto

Hører ikke til organisationsadministrationen. Sletning af en personlig konto (GDPR-retten til sletning) ligger under User settings → Account. Se Your fremforge account for hele forløbet, herunder hvad der bevares som historisk tilskrivning.

Branch protection, begrebsoversigt

Branch protection følger et hierarki i tre niveauer: platformens minimum (sat af fremforge, kan ikke konfigureres) → organisationens standard (sat af organisationens ejer, gælder alle repositories) → regler pr. repository (kan stramme organisationens standard, men ikke løsne den under organisationens minimum).

Organisationens standardbeskyttelse: Organisationsadministration → Standarder for repositories → Branch protection. Sæt regler, der gælder for alle nyoprettede repositories og for alle eksisterende repositories, hvor der ikke findes en strengere regel på repositoryniveau.

Beskyttelse pr. repository: Repository → Settings → Branches → Add rule. Angiv et mønster for branchnavne (fx main, release/*). Tilgængelige beskyttelser:

Platformens minimum: Platformen håndhæver følgende: signerede commits er tilladt (ikke påkrævet) på platformsniveau; scanning for secrets kører uanset indstillingerne for branch protection; revisionsloggen registrerer alle force-push-hændelser, også selv om force-push ikke er blokeret.

Arv af politikker: Kræver organisationens standard 1 review på pull requests, og en regel på repositoryet kræver 2, vinder den strengeste regel (2). Regler på repositoryniveau kan kun stramme, ikke løsne.

Dataeksport

frem.sh/<org>/_admin/data-export: fuld selvbetjent eksport.

• Start en ny eksport: samler én signeret .tar.gz med et git bundle pr. repository, hvert repositorys issues, pull requests, kommentarer, labels, milepæle og releases, pakkeoversigten og et udsnit af revisionsloggen for 90 dage. Se Dataeksport for præcis, hvad den indeholder.
• Seneste job: de sidste 20 eksportjob med downloadlinks (gyldige i 7 dage, efter at eksporten er klar) og status.

Begrænset til én eksport pr. organisation pr. 24 timer. Bundter over 50 GB følger en anden procedure. Kontakt support.

Se dataeksport for bundtets struktur, opskrifter på verifikation og API-endpoints.

Indstillinger

frem.sh/<org>/_admin/settings: organisationens grundlæggende metadata: synlighed (public / limited / private), visningsnavn, beskrivelse, website og placering. Ændringer her videresendes til Forgejo via PATCH /api/v1/orgs/{org} og udsender revisionshændelsen tenant.org.settings.updated.

Indstillinger, der håndteres andre steder:

• Organisationens navn (slug): omdøbning af slugget er en Forgejo-handling med 90 dages omdirigering. Den håndteres i Forgejos egen brugerflade under /<org>/-/settings.
• Avatar / profilbillede: Forgejos egen brugerflade under /<org>/-/settings.
• Fakturering, SSO, sikkerhedspolitik, push-beskyttelse: se de dedikerede faner ovenfor.

Grænsen går her: fremforge-administrationen står for organisationens navn (visning), synlighed, website, beskrivelse og placering samt de dedikerede faner for abonnement, politik, sikkerhed og revision. Forgejos egen brugerflade på /<org>/-/settings står for avatar / profilbillede, omdøbning af slug, Forgejos interne standarder for oprettelse af repositories og dybere konfiguration, der kun findes i Forgejo. Begge kan nås fra ejerkonti; vælg den flade, der passer til den ændring, du vil lave.

Revisionslog

frem.sh/<org>/_admin/audit-log: alle administrative handlinger, der ændrer tilstand i din organisation, kan gennemses i realtid.

• Filter på aktør: afgræns til en bestemt Forgejo-bruger eller til operatørhandlinger (med præfikset operator:<email>).
• Filter på handling: afgræns til et navnerum (fx push-protection eller billing.cancel).
• Filter på tidspunkt: afgrænset efter dato.
• Operatørmærke: handlinger, som fremverks medarbejdere udfører på vegne af din organisation, fremhæves med orange og sker aldrig i det skjulte. De samme data kommer med i revisionsudsnittet i dit dataeksportbundt.

Ældre hændelser afskæres efter 200 rækker på skærmen. Skal du bruge hele historikken, så brug Dataeksport. Revisionsudsnittet i bundtet er ikke begrænset.

Opbevaring. I henhold til DPA bilag A.7 ligger sikkerhedsrelevante hændelser (autentificering, autorisation, administrative handlinger) i et søgbart varmt lag med en opbevaringsperiode pr. organisation, som du sætter under Sikkerhed → Godkendelsespolitik → Opbevaring af revisionslog: de faste valg er 90 / 180 / 365 / 730 dage, med 90 (standardplan) eller 365 (enterprise-planer) som standard. Driftslogs (HTTP, runner, infrastruktur) holdes i det varme lag i 30 dage (kan ikke konfigureres). Begge lag skrives til et uforanderligt WORM-arkiv på T Cloud Public OBS i 3 år med forankring af en hashkæde hvert 2. minut, så manipulation kan påvises. Efter det varme lags frist redigeres payloadet (actor, fields_json) væk, men SHA-256-hashene i kæden bevares i alle 3 år. Visningen på skærmen og revisionsudsnittet i dataeksportbundtet dækker begge den konfigurerede periode i det varme lag. Skal du bruge ældre hændelser fra WORM-arkivet, så kontakt support@frem.sh.

API-ækvivalens

Hver administrativ handling findes også som et dokumenteret REST-endpoint. Administrationen er selv en klient af det samme API, som en AI-agent ville bruge. Se det offentlige REST API for OpenAPI-specifikationen.

To navnerum, én værtsadresse. Ruter under /api/v1/... er Forgejos egne (samme form som upstream Forgejo API, uden fremforge-præfiks, og bruges til oprettelse, læsning, opdatering og sletning af organisationer, repositories, brugere, issues og pull requests, som Forgejo allerede dækker). Ruter under /_app/api/v1/... er fremforges udvidelser (de tilføjelser til kontrolplanet, vi lægger ovenpå: fakturering, push-beskyttelse, dataeksport, hostet Renovate, SSO-politik og attestationer). Kaldet PATCH /api/v1/orgs/{org}, som nævnes under §Indstillinger ovenfor, er Forgejos egen form; den samme vært betjener begge præfikser via platformens routing. Brug det præfiks, der passer til det dokumenterede endpoint, og bland dem ikke.

Alt, hvad du gør i administrationen, kan du altså også gøre programmatisk:

• POST /_app/api/v1/orgs/<org>/dependency-updates/enrol svarer til at klikke på “Enable hosted Renovate” (fremforge-udvidelse)
• POST /_app/api/v1/orgs/<org>/exports svarer til at klikke på “Start en ny eksport” (fremforge-udvidelse)
• GET /_app/api/v1/orgs/<org>/push-protection/overrides lister de aktive undtagelser fra push-beskyttelse (fremforge-udvidelse)
• PATCH /api/v1/orgs/<org> opdaterer visningsnavn / website / placering / synlighed (Forgejos egen)
• …osv.

Autentificering med token: en PAT udstedt fra dine brugerindstillinger i Forgejo. OAuth 2.0 client credentials er planlagt sammen med flowet for agentidentitet.

Revisionsspor

Hver administrativ handling udsender en struktureret loglinje til fremforges revisionsstrøm med felterne actor, action, tenant_id og felter, der afhænger af handlingen. Revisionsloggen er med i bundtet fra dataeksporten, afgrænset til din organisation.

Det ser du i dit revisionsudsnit:

• Alle POST- og DELETE-handlinger i administrationen (alt, der ændrer tilstand)
• Alle API-kald, der er autentificeret som et medlem af din organisation
• Alle operatørhandlinger, som fremverks medarbejdere udfører på vegne af din organisation (de er markeret med actor=operator:<email> og sker aldrig i det skjulte)

Det ser du ikke (af hensyn til privatliv og retlige processer):

• fremverks interne infrastrukturhændelser (de går til en separat revisionsstrøm)
• Korrelations-id’er på tværs af organisationer (fjernes før eksport)

Krydshenvisninger

• Priser: hvad der er inkluderet i planen til 30 € pr. plads
• Trust: underdatabehandlere, certificeringer og suverænitet
• Offentligt REST API: programmatiske modstykker til alle administrative handlinger
• Migreringsguides: trin-for-trin-opsætning fra GitHub / GitLab / Azure DevOps