Trust

Effective Date: 2026-05-19 - Version: 1.13

Last updated: 2026-10-07

Summary #

fremforge is EU-sovereign Git hosting built on upstream Forgejo and operated by fremverk ApS (Denmark). Every surface runs in the European Union. No customer data leaves EU jurisdiction.

Every processing surface (repositories, CI, audit, billing, authentication, outbound email, inbound shared-mailbox correspondence) runs on entities with no US parent. Zero US-parented sub-processors on any path. See the product DPA §11.3 for the full posture.

This page is the canonical reference for where your data lives, who processes it, what certifications apply, and how to reach us.

Data controller #

fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Denmark Email: compliance@frem.sh · info@fremverk.com

Hosting and regions #

Sub-processors #

The current sub-processor list is maintained here. Any change is announced 30 days in advance to the security mailing list and on this page.

Bot mitigation does not involve a third-party processor. The product signup and login forms use self-hosted Altcha (MIT-licensed, HMAC-signed proof-of-work) running in-process inside the api monolith on the same T Cloud Public cluster; no third-party widget JS, no external sub-processor. Additional server-side controls (per-IP throttling and rate limits) apply across the surface. No Web Application Firewall is enabled at the edge; see §Edge protection below.

Edge protection - DDoS mitigation, no WAF #

Every fremforge surface (frem.sh for Forgejo and Git, the API, and the www, docs, status and CLI sites) sits behind the Bunny CDN edge, which provides volumetric DDoS mitigation and per-IP rate limiting. No Web Application Firewall (WAF) is enabled at the edge on any fremforge surface, and none has been since before go-live. The decision is intentional. During pre-launch testing the OWASP Core Rule Set produced a high false-positive rate on Forgejo’s request shapes (Git protocol paths, pull-request diff routes, raw-blob fetches with hex-string identifiers, signed-URL query strings) and on the API’s form bodies. An over-aggressive WAF that breaks legitimate Git operations or Forgejo UI flows would have been a worse outcome for customers than the residual edge-layer risk. Mitigation lives in the application instead: pre-receive secret scanning, Altcha proof-of-work on signup and login, per-IP and per-tenant rate limits in the API, signed-token authentication on every webhook receiver, and the audit-chain integrity hash. This posture is set out in DPA Annex A.2 and re-reviewed at each quarterly operational review.

Hosted-runner isolation - ephemeral ECS VM, one per commit #

CI jobs you push to fremforge run on T Cloud Public Elastic Cloud Server (ECS): each commit or pull request gets its own ephemeral virtual machine, provisioned fresh and destroyed once that commit’s jobs finish. Two independent layers of isolation:

• Compute / kernel - a dedicated VM per commit. Every commit’s jobs run in an ECS virtual machine with its own Linux kernel, isolated by the hypervisor. No two customers, and no two commits, ever share a kernel or a machine, so kernel-side container-escape primitives (cgroup-escape, /proc bind-mount escape, eBPF, /sys exposure) have no cross-tenant boundary to cross: there is no shared kernel to escape into. The isolation unit is a whole VM, not a container - a stronger boundary than the shared-kernel container model that conventional Kubernetes (CCE included) uses for runner pods. The VM is reaped (deleted) once that commit’s jobs complete, so nothing - build cache, cloned code, injected secrets - persists into another commit’s jobs or into any other customer’s.
• Within one commit, jobs may share the machine. Successive jobs of the same workflow run (for example build then deploy over the same commit) may execute on the same VM, which is destroyed when they finish. That is deliberate: it is the same reviewed code in both jobs, and a fresh machine per job costs roughly 40 seconds of extra dispatch latency on every step of a pipeline. The consequence worth stating plainly is that a build step which executes third-party dependency code shares a machine with a later step of the same commit, so treat a pipeline as a single trust domain and scope any credential a deploy step needs to that pipeline. Cross-tenant and cross-commit isolation above is unaffected by this.
• Network - per-VM VPC Security Group. Each runner VM sits behind its own VPC Security Group: no inbound access, VM-to-VM (intra-subnet) traffic denied, and egress restricted to the SSRF-guarded outbound runner-proxy, the Forgejo API, and DNS. Isolation is enforced at the VPC/hypervisor layer, not at an in-cluster NetworkPolicy layer that depends on a CNI agent behaving correctly. Combined with the forced outbound proxy and its SSRF deny-set, lateral movement from a runner VM to anything outside the customer’s own job context is denied at both the VM and VPC layers.

If T Cloud Public’s isolation model for either layer changes in a direction that weakens the above (e.g. per-job VMs are replaced with shared-kernel containers, or the per-VM Security Group boundary is removed), this page is updated within 30 days of the change and any active Customer is notified per DPA §14.

Inherited certifications #

Through T Cloud Public:

• ISO/IEC 27001 - information security management
• ISO/IEC 27017 - cloud-specific security controls
• ISO/IEC 27018 - protection of personal data in the cloud
• BSI C5 Type 2 - German federal cloud-security baseline
• TISAX - German automotive industry assurance
• GDPR-compliant processing in EU data centres

fremverk’s own certification roadmap #

As of the Effective Date, fremverk does not hold standalone ISO 27001, SOC 2, or BSI C5 certifications. fremverk’s security posture rests on (i) the inherited certifications of its sub-processors listed above, (ii) the technical and organisational measures in the DPA security annex, and (iii) fremverk’s information security and security-testing programme described in the DPA security annex.

fremverk has committed to:

• Commencing ISO 27001 Stage 1 audit within 18 months of the Effective Date and achieving certification within 24 months.
• Commencing a SOC 2 Type II readiness assessment within 24 months.

Customers requiring direct certification before those milestones may contract under Enterprise-on-Demand with the certification-readiness milestones written into the Order Form. See DPA §12.1.

Government access transparency #

As of the Effective Date, fremverk has received zero government-access requests for Customer Personal Data. The full report - including the partial-period statement covering pre-launch operations - is published at frem.sh/trust/transparency/. Subsequent reports cover full calendar years and publish in Q1 of the following year.

Where fremverk receives a binding legal demand from a government authority, court, or law-enforcement agency, fremverk:

• Reviews the request for legal validity, jurisdiction, and proportionality;
• Challenges any request that is overbroad, lacks lawful basis, or conflicts with EU law (including GDPR Art. 48 for non-EU/EEA requests);
• Notifies the affected Customer within 24 hours of receipt unless legally prohibited from doing so;
• Provides the Customer with reasonable opportunity to seek a protective order or otherwise contest the request.

See DPA §11A.

DSA transparency report (Article 15) #

fremforge is a hosting service within the meaning of Regulation (EU) 2022/2065 (Digital Services Act). The annual Art. 15 report on notice-and-action volumes, member-state authority orders, own-initiative content moderation, and Art. 20 complaint outcomes is published at frem.sh/trust/dsa/ - separate from the government-access report above. The same URL carries the six-monthly average-monthly-EU-recipients figure required by Art. 24(2).

Schrems II - international transfers #

No international transfer of Customer Personal Data occurs on any processing path. All processing (repository content, CI runs, audit logs, authentication metadata, billing records, payment-instrument data, outbound transactional email, and inbound shared-mailbox correspondence) takes place inside the EU/EEA at entities with no US parent. No Article 46 GDPR safeguard, SCC, or transfer impact assessment is required.

Edge-PoP residency (Bunny CDN) #

Every Bunny pullzone in front of frem.sh is configured to serve from EU PoPs only - no US, AU, or Asia caching. This is enforced in OpenTofu on each pullzone resource via routing { zones = ["EU"] }. The pullzone configuration lives in the source tree at:

• Forgejo pullzone: fremforge/forgejo/.infrastructure/main.tf - search zones = ["EU"]
• API pullzone: fremforge/monolith/.infrastructure/bunny.tf - same line
• Static-site pullzones (www, docs, status, cli) inherit the same routing block from the shared module at fremverk/cloudplatform/modules/static-site/main.tf:103-112.

A tofu plan against any pullzone stack prints the active routing.zones value, so any drift away from ["EU"] would surface as a plan diff. Auditable evidence will become directly browsable once the source tree is hosted on the customer-facing Forgejo instance (at https://frem.sh/fremforge/...); for now, the canonical audit-chain anchor and integrity-verifier documentation is published at docs.frem.sh/security/audit-chain/.

TLD note #

frem.sh is a Saint Helena (.sh) ccTLD administered by a UK-registered registry operator. This is a DNS-level fact only. No customer data, no control-plane state, and no backups leave T Cloud Public EU-DE. The sovereignty guarantees (processor identity, sub-processor list, data residency) are set out in the DPA and are unaffected by DNS hosting.

Zero CLOUD Act exposure on any processing path. All Customer Personal Data is processed inside the EU/EEA by entities with no US parent. See DPA §11.3 for the full posture.

Card-network footnote. Mollie’s PCI-DSS-attested card-processing chain involves Visa Europe Services Inc. (UK branch) and Mastercard Europe SA (Belgium) - EU operating entities whose ultimate parents (Visa Inc., Mastercard Inc.) are US-incorporated. The “no US-parented” claim applies to fremverk’s own sub-processor stack at the operating-company level; the card networks are sub-sub-processors of Mollie under PCI-DSS network rules. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit (no card-network involvement). See subprocessors - Card-network footnote.

Verify the audit chain yourself #

Every state-changing admin action on your org is recorded in a per-tenant SHA-256 hash chain, with the chain head WORM-anchored every two minutes to T Cloud Public OBS Object Lock storage (3-year retention, physically un-deletable within retention). You can walk the chain end-to-end without trusting fremverk’s word for it.

With the fremforge CLI:

# Install (one-liner; see docs.frem.sh/get-started/cli/ for manual download + SHA-256 verify)
curl -sSfL https://cli.frem.sh/cli/install.sh | sh

export FREMFORGE_TOKEN='<your PAT, audit:read scope>'
fremforge audit-verify <your-org-slug> --human

Or with raw curl against the same endpoint the CLI calls:

curl -sSf \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  https://frem.sh/_app/api/v1/orgs/<your-org-slug>/audit/integrity \
  | jq '{integrity_status, walked_rows, verified_count, last_verified_hash, worm_anchor}'

A healthy response reads "integrity_status": "ok" and includes a worm_anchor block whose agrees_with_db_walk: true confirms the in-database chain matches the OBS-anchored head. A break (hash_mismatch / prev_hash_mismatch) returns the offending row id and reason - designed to be auditor-readable. Full schema, exit codes, and the threat model in docs.frem.sh - audit-chain integrity.

Operator credential custody #

Bootstrap admin credentials (the domain-scoped T Cloud Public root AK/SK used only for first-time IAM, OBS bucket, and service-linked agency creation) are stored on the operator laptop with FileVault full-disk encryption and chmod 600 file permissions, rotated quarterly, never transmitted via chat or screen-share, and revocable in under 10 minutes via the OTC console. Routine deploys use per-component scoped deployer keys, not the root credential.

Security contact #

• Report vulnerabilities: security@frem.sh
• Disclosure policy: security
• PGP key fingerprint: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (public key - RFC 4880 armored, RSA-4096, expires 2031-05-14). Use for encrypted vulnerability reports to security@frem.sh. The key is published only from frem.sh/.well-known/; we do not upload to public keyservers (avoids the third-party trust root). Mirror at /pgp.txt for convenience.

Vulnerability disclosure #

A machine-readable disclosure policy is published at frem.sh/.well-known/security.txt per RFC 9116, including safe-harbour for good-faith research, scope, and reporting channel. Third-party penetration test reports, when commissioned, are made available to Customers under NDA on written request per DPA §12.1; Enterprise-on-Demand contracts may agree to a specific testing cadence in the Order Form.

Incident disclosure #

Post-mortems for any incident affecting customer data or availability are published on this page within 14 days, per our security policy.

Security patching #

fremforge commits to the following maximum time-to-patch for security vulnerabilities in the platform, measured from the upstream fixed release or advisory publication, whichever is later.

Out-of-band emergency releases are expected. The weekly maintenance window is a ceiling, not a floor. Security patches are never deferred to honour a tenant maintenance window; this is stated in the AUP and cited verbatim in the DPA security annex.

Exit and data portability #

Everything is exportable - repositories, issues, pull requests, Actions logs, audit trail, SLSA attestations - via API as standard formats. There is no retention lock-in and no export fee.

Self-service tamper-evident export. Any tenant admin can trigger a full bundle from the admin UI at any time. The bundle is delivered as a single zip with a SHA-256 manifest covering every file in the archive (manifest.json + archive.tar.gz.sha256) so the customer can confirm the contents haven’t been tampered with after download. The bundle contains repo git bundle files, LFS manifests, Actions logs, audit slice, and SLSA attestations. For comparison, GitHub’s organisation export is a set of REST API calls, available to organisation owners, that produces an archive meant for import into GitHub Enterprise Server (GitHub docs, read 17 October 2026). fremforge ships it on every plan, every customer, every day. The manifest is signed with our SLSA builder key (DSSE envelope, manifest.json.intoto.jsonl); customers verify with the same trust root at https://www.frem.sh/.well-known/slsa-trust-root.json published for SLSA build attestations. Verifying the manifest needs no Sigstore at all — neither the public good instance, nor the self-hosted Fulcio and TSA we run as a second signature on build attestations. See docs.frem.sh/data-export for the bundle layout, verification recipes, and the API endpoints.

Tenant offboarding timelines and procedures are spelled out in the DPA.

Cookies and tracking #

fremforge sets only strictly-necessary cookies on authenticated product surfaces, and zero cookies on marketing, docs, status, and anonymous pages. No consent banner needed: not because we hid the question, but because we don’t set cookies that would require consent.

Authenticated product surfaces set four first-party cookies, all strictly-necessary under ePrivacy Directive Article 5(3):

Marketing, docs, and status (www.frem.sh, docs.frem.sh, status.frem.sh) are Hugo-built static sites with no cookies, no analytics, no embeds, and no tracking of any kind. Verifiable in your browser’s developer tools.

Third-party calls from the product UI are disabled by default: no Gravatar, no federated avatars, no CDN-loaded fonts or scripts, no third-party analytics. Avatars are stored locally; fonts are served from the same origin as the forge.

This is a deliberate product posture, not a compliance minimum. Full cookie inventory and data-subject rights are documented in the product privacy policy.

Changes to security measures #

The DPA Annex A lists the technical and organisational measures fremverk applies, and says that material changes to them are notified here. Changes from 2026-10-04 onward are listed below, newest first; earlier changes are recorded in the DPA change log. A change that reduces a commitment takes effect 30 days after a notice to every Customer administrator, with the termination right in Terms §17; the others take effect on publication. Each version links to its text.

Changes to this page #

Changes are versioned in Git and announced on the security mailing list. The date at the top of this page reflects the last meaningful content change.

Change log #