Fjord

What we guarantee, and what runs underneath.

Written for the person who has to sign off on moving a company's source code. The guarantees first, then the isolation model, then the limits and how to leave. The implementation detail is at the end, as evidence rather than as the subject.

What we guarantee

Six commitments, each with the qualifier that makes it true. Read the bold line in each card for the claim, the paragraph under it for the detail.

Isolation

One Forgejo, one machine, one customer.

Your Forgejo runs on a machine of its own, with its own database and storage volume. Not a namespace on a shared cluster, and no cross-customer table for a query bug to spill across.

Operations

We carry the pager, not you.

Updates, TLS, runner capacity, monitoring, and restores are ours to run. Nobody on your team becomes the forge admin.

Backups

Nightly and encrypted, on Team and Pro.

Encrypted before they leave your instance and kept on a rolling 90-day window in a store dedicated to your forge. Starter has no managed snapshot backups.

Updates

Upstream Forgejo, patched for you.

You run upstream Forgejo, not a fork we control. We track releases and apply them for you, security fixes first, with no maintenance window to book.

Security

Narrow access, and a ledger of it.

Per-instance secrets come from a root key held only in the control plane. Inbound access is firewalled, administrative endpoints require MFA, and a tamper-evident ledger records admin actions.

Data ownership

Open format, open exit.

Forgejo is open source and the on-disk format is upstream. Export through the API any time, or ask for a full dump. Nothing proprietary sits in the middle to trap you.

The isolation model

One instance, top to bottom. Everything between your team and your backups is dedicated to you.

  1. Your team

    Browser, fj CLI, and the iOS app, over HTTPS to your own hostname

  2. A dedicated VM

    One per instance, single-tenant, in the region you choose

    • Upstream Forgejo

      A pinned upstream release, on your own hostname

    • Its own database

      Scoped to this instance. No cross-customer tables.

    • Its own storage volume

      Repositories and attachments, on the instance volume

  3. Encrypted backups, off the box

    Team and Pro. Nightly, encrypted client-side, to a jailed store of its own.

Your instance is yours alone, not a tenant sharing a database with other customers' code. There is no common pool to leak across, mine, or train on. CI runners are separate machines and are not shown here: by default a pool we operate, with runners dedicated to your forge available as an add-on.

Current limitations

These are current limitations, listed on purpose so you know exactly what you are buying.

What we do not guarantee

  • No SOC 2, no ISO 27001, and no contractual uptime SLA. Support response targets are targets, not guarantees.
  • Restore is operator-run against a runbook we are still validating end to end. We publish no recovery-time commitment, and because backups run nightly the recovery point is the last nightly snapshot.
  • Backups are not yet pinned to your instance region. Instance and runner placement are.
  • CI jobs run on a runner pool we operate unless you add a dedicated runner. Single-tenancy of the forge itself is unconditional; single-tenancy of the CI machine is the add-on.

If your procurement requires a certification or a contractual SLA, we are not the right fit yet. We would rather say so here than in month three.

How you leave

Open format, a per-repository migration or a full dump, and a delete that takes everything with it.

The honest test of an architecture you are trusting with source code is how cheaply you can walk away from it.

Forgejo is open source and GPL-3.0-or-later from v9 onward, and your instance is a standard one. So exporting your data is a per-repository migration through the Forgejo API, or a full forgejo dump archive on request. Deleting an instance tears down its machine, its DNS records, and the tokens we hold for it. Single-tenant never turns into a single point of lock-in.

Implementation details

The evidence behind the guarantees: how the isolation is built, where each category of data lives, and who can reach it.

How the isolation is built

Deploying a forge provisions a machine for it, running an upstream Forgejo release with its own database and data volume, on your subdomain or your own custom domain. It starts, updates, and stops on its own schedule. No multi-tenant control surface sits in the request path of your repositories.

CI is the one place the default is shared. Every plan includes capacity on a runner pool we operate and patch. On Team and Pro you can attach runners registered to your forge and nothing else, at $29/mo each, up to 1 on Team and 3 on Pro. Those are unmetered: no build minutes to count. Runner machines expose no inbound services either way.

Isolation is what makes the rest of the site's promises cheap to keep. Never training AI on your code is easy to honor when there is no shared corpus, and private by default is real when there are no neighbors to be private from.

Where your data lives

You choose the region. Your instance and runner machines stay in it; backups do not yet.

Instance and CI runners
Hosted by Hetzner in the region you choose: EU Central (Falkenstein), United States, Asia Pacific (Singapore). New instances default to EU Central (Falkenstein). We do not replicate forge contents to other regions.
Backups
Backups are currently stored in EU (Helsinki, Finland) for every Instance, whichever region you choose; per-region backup storage is being rolled out. On Team and Pro, each forge backs up to a jailed store of its own, encrypted client-side before anything leaves the instance, on a rolling 90-day window.
Analytics and error reporting
Service analytics and error reporting are processed in the EU.
Operations
Fjord is operated from the United States by Raster & State LLC, and is offered to United States customers today. Operational and audit logs are kept for 90 days.

Where each category of data lives, backups included, is set out per category in the Data Residency Statement.

How we keep it running, and who can touch it

We patch it, we hold the certificates, and operator access is narrow and logged.

Updates
We track Forgejo releases and apply them for you, security fixes first, so you are current without reading a changelog to find out what broke. Runner capacity is provisioned, registered, and patched by us.
Certificates
Provisioned and renewed automatically. Your forge is HTTPS from the first request.
Operator access
Per-instance secrets derive from a durable root key held only in the control plane, fetched over TLS at first boot and never placed in the machine's user-data channel. Inbound access is firewalled, with administrative access limited to the control plane. Sensitive administrative endpoints require MFA, and we do not read repository or CI contents except to provide, secure, and support the service.
Audit trail
Administrative actions land in a tamper-evident ledger.

Each of these is on the record in the security annex of the Data Processing Addendum, and the full current-state detail is on the security page.