Sovereign git, config as code, and how we built the Vault

Your data and your config should actually be yours

We keep coming back to a simple test for any FastYoke feature that touches customer data: if we disappeared tomorrow, could you still get your data out, in a form you could read, in a form you could verify? Not a support ticket. Not a proprietary export format. Not "trust us, here's a CSV."

That test pushed us toward a substrate that already has the right properties built in: git. Config as code is not a new idea — it's the same discipline the GitOps community has been formalizing for infrastructure for years: describe desired state declaratively, keep it in version control, let the history of commits be the audit trail. We didn't invent this pattern. We noticed that our own house was already built on it, and that tenants deserved the same foundation.

Here's the thing that made this an easy decision rather than a speculative one: FastYoke's own source code and CI already run on self-hosted Forgejo, a self-hosted git service. We're not proposing git as a tenant-data substrate in the abstract — we run our engineering org on it every day. Extending that same infrastructure to materialize tenant data as commits was less "adopt a new technology" and more "point the thing we already trust at a second problem."

Why the usual answers fall short

Most SaaS platforms answer "can I get my data out" with one of three unsatisfying options.

A proprietary export. A button that produces a JSON or XML dump in a shape only that vendor's importer understands. It technically satisfies "you can download your data," but it's not portable in any meaningful sense — you can't diff it, can't replay it, can't hand it to an auditor and have them independently verify anything about it.

An opaque backup. Your data exists somewhere, backed up on some schedule, in some format, and you're told it's safe. You have no way to inspect it, no way to confirm the backup that ran last Tuesday actually captured what you think it captured, and no way to detect if a byte of it was altered after the fact.

A "trust us" audit log. Most audit trails are a database table. Someone with sufficient privilege on that database can edit a row, and unless you're independently monitoring the raw storage, you'd never know. The audit log's integrity depends entirely on trusting the platform operator not to touch it — which is a strange thing to ask an auditor to accept.

None of these give a customer something they can hold, inspect, and verify independently of the vendor that produced it. That's the gap the Vault closes.

The Vault: a git repo that is your app, continuously

For every tenant on our Team and Enterprise tiers, FastYoke provisions a private Forgejo repository and keeps it up to date. A background worker runs on a steady cadence and, for each qualifying tenant, does two things:

1. Materializes the app definition as files. Your FSM schemas, forms, UI pages, roles, and configuration — the config-as-code shape of "what your app is" — get written out as a structured file tree and committed.
2. Appends the event ledger. FastYoke's event_log — the append-only record of every state transition, every administrative override, every FSM event that ever fired for your tenant — gets drained into newline-delimited JSON files and committed alongside the definition.

This is deliberately a one-way projection. The live database and the live event log remain the source of truth for everything FastYoke does at request time; nothing about serving your app depends on Forgejo being up. The Vault is downstream — a continuously refreshed mirror, not a second system you have to keep in sync by hand. If the git side is briefly unreachable, the app doesn't notice; the worker just catches up on its next pass.

The result is a private repository you can clone. Not an export button you click once — a live git history that keeps growing as your business runs, in a format that's just text: JSON and NDJSON files, tracked commit by commit.

Why git makes the audit trail provable, not just claimed

This is where git stops being "a convenient place to put files" and starts doing real work.

Every object in a git repository — every file, every tree, every commit — is identified by a cryptographic hash of its own contents. A commit's hash depends on the hash of the tree it points to, which depends on the hashes of the files in it, which depends on the hash of the previous commit. Change one byte anywhere in that history and every hash downstream of it changes. This is the same Merkle-tree construction that gives content-addressed systems their tamper-evidence: you don't have to trust a claim that nothing was altered, you can recompute the hashes yourself and check.

That property is exactly what an append-only ledger needs. FastYoke's event_log already never accepts an UPDATE — it's structurally insert-only. Projecting it into a git history means that guarantee stops being "a rule our code follows" and becomes "a chain you can independently verify." If someone tried to rewrite history — insert a different event, delete one, alter a timestamp after the fact — the hash chain breaks in a way that's detectable without needing access to our production database at all.

On top of that chain, FastYoke can periodically hand a tenant a signed receipt of the current head hash — a small, independently verifiable statement of "this is what the ledger looked like as of this commit." A tenant (or their auditor) can hold onto that receipt, and later confirm the repository's history hasn't been rewritten underneath them, entirely offline, without asking us to vouch for anything.

The four things this substrate buys

Once the materialization pipeline exists, four capabilities fall out of it more or less for free, because they're all just different ways of looking at the same git history.

Portability. git clone the repo and you have your entire app definition and your entire event history, in a format that isn't proprietary to FastYoke. Walk away, and you still have something readable and replayable.

Audit. The hash chain described above turns "we promise the log is append-only" into something a third party can check without trusting us.

Backup and disaster recovery. Because the event ledger is event-sourced by design, the materialized ledger isn't just a record — it's a recovery path. A tenant's state can, in principle, be rebuilt by replaying the ledger forward, independent of whatever backup tooling FastYoke runs internally.

GitOps-style authoring. Once your app definition lives as files in a git repo, the door is open to the workflow the GitOps community already uses for infrastructure: propose a change as a diff, review it, merge it, and have the merge become the new authoritative version of your app. That's a further-out layer we're building toward, not something the Vault does on day one — but it's the natural next step once the substrate exists.

The payoff: sovereignty you can prove, not just claim

We keep saying "your data is yours" is meaningless unless you can act on it without our permission. The Vault is our attempt to make that literal. A qualifying tenant can clone their repository, hold their own copy of every event that ever happened in their account, verify that history hasn't been silently rewritten, and do all of that fully offline if they choose to. That's a materially different posture than a vendor telling you your data is safe with them.

It's also a natural extension of a decision we'd already made. We didn't stand up Forgejo for this feature — we already run our own source and CI on it, self-hosted, because we didn't want a third party sitting between us and our own engineering history. The Vault is the same instinct, pointed at the data you trust us with.

This sits alongside two other posts on how FastYoke is built: why we run tenant logic in a WebAssembly sandbox, and why FastYoke DB ships two flavors of distributed SQL. For the deployment and compliance side of sovereignty, visit our Trust Center or read about running FastYoke on your own infrastructure.