Trust

Effective Date: 2026-05-19 — Version: 1.5

Last updated: 2026-05-19

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 waitlist relies on layered server-side checks (honeypot, dwell-time, per-IP throttling, edge WAF). The Forgejo signup form uses self-hosted Altcha (MIT-licensed, HMAC-signed proof-of-work) running in-process inside the api monolith on the same T Cloud cluster; no third-party widget JS, no external sub-processor.

Edge WAF — Bunny Shield posture (launch baseline) #

The Bunny CDN pullzones in front of frem.sh (Forgejo) and the api surface (/_app/*) run Bunny Shield Basic at launch, not Shield Advanced. Shield Basic provides volumetric DDoS mitigation, rate limiting, and IP/geo/bot signal filtering; the OWASP Core Rule Set (CRS) WAF available in Shield Advanced is not enabled on these two pullzones. The decision is intentional: Forgejo’s URL patterns (Git protocol paths, pull-request diff routes, raw-blob fetches with hex-string identifiers, signed-URL query-strings) produced a high false-positive rate against the upstream CRS during pre-launch testing; an over-aggressive WAF that breaks legitimate Git operations or Forgejo UI flows would have shipped a worse customer outcome than the residual edge-layer risk. Mitigation lives in-app rather than at the edge: pre-receive secret-scanning, Altcha PoW on signup/login, per-IP and per-tenant rate limits in the Hono middleware, signed-token auth on every webhook receiver, and the audit-chain integrity hash. The static-site pullzones (www, docs, status, waitlist, cli) run Shield Advanced with CRS enabled because their request shape is regular static-HTML traffic where CRS does not false-positive. The Forgejo/api Shield posture will be re-evaluated after 90 days of false-positive telemetry on a canary subset with Shield Advanced enabled.

Hosted-runner isolation — CCI Kata + Yangtse v2 #

CI jobs you push to fremforge run on T Cloud Cloud Container Instance (CCI), a serverless container runtime designed for multi-tenant workloads. Each customer’s runner pod gets two independent layers of isolation:

• Compute / kernel — Kata Containers (per-pod micro-VM). CCI runs every pod inside its own Kata-Containers lightweight VM with a dedicated Linux kernel. There is no shared kernel between two customers’ runner pods, so kernel-side container-escape primitives (cgroup-escape, /proc bind-mount escape, eBPF, /sys exposure) cannot cross the tenant boundary — at worst they escape into the per-pod VM, which itself contains no other tenant’s data. This is materially stronger than the shared-kernel model that conventional Kubernetes (CCE included) uses for runner pods. See T Cloud’s documentation at docs.otc.t-systems.com/cloud-container-instance/umn/product_description/concepts.html for the platform-level isolation claim.

  During the T Cloud CCI v2 OBT-entitlement waitlist period, hosted runners execute on standard CCE node-pools with the hardening posture documented in DPA §A.4; the Kata-Containers micro-VM isolation claim above takes effect once the OBT entitlement unlocks on our tenant. This carve-out mirrors DPA Annex A’s runner-isolation language verbatim and is updated when the entitlement lands.

• Network — Yangtse v2 (per-namespace VPC ENI). Each customer’s runner namespace gets its own Yangtse v2 Network resource bound to a dedicated VPC subnet + security group. Pod traffic terminates on a per-namespace ENI in our VPC; there is no shared pod-network bridge across customers. Network isolation is therefore enforced at the VPC layer, not at an in-cluster NetworkPolicy layer that depends on the CNI agent behaving correctly. Combined with the per-pod outbound proxy and egress allowlist, lateral movement from a runner pod to anything outside the customer’s own job context is denied at both the VM and VPC layers.

If T Cloud’s published documentation on either layer changes in a direction that weakens the above (e.g. Kata is replaced with shared-kernel containers, or Yangtse is replaced with a shared pod-network), this page is updated within 30 days of the platform change and any active Customer is notified per DPA §14.

Inherited certifications #

Through T Cloud:

• 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, waitlist, 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 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 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, walked_rows, verified_count, last_verified_hash, worm_anchor}'

A healthy response reads "integrity": "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 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. GitHub and Azure DevOps do not offer an equivalent one-click self-service export; their portability paths require either Enterprise tier or support tickets. 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. No Sigstore dependency. 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 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 #