The escape hatch is a feature, not a support ticket. Any owner or admin can take a workspace's full knowledge and governance state out as a single archive, whenever they like.
We think this is worth being loud about. A shared-context product that's hard to leave is one you shouldn't put your team's context into.
What you get
A .tar.gz laid out as the product's mental model, not the database schema. Everything textual is markdown with YAML frontmatter, so a human reads it in any editor, an AI ingests it without a parser, and grep works. Binaries are byte-for-byte.
Roughly:
manifest.yaml
spaces/<space>/space.yaml metadata, tag definitions, notification rules
spaces/<space>/memories/<project>/<title>.<id>.md
spaces/<space>/collections/<title>.<id>/collection.yaml
spaces/<space>/collections/<title>.<id>/<version>/… artifact bytes + .meta.yaml
spaces/<space>/collections/<title>.<id>/feedback.yaml comments + approvals, version-pinned
spaces/<space>/wikis/<slug>/wiki.yaml name, description, approval policy
spaces/<space>/wikis/<slug>/pages.yaml the tree: paths, parents, states
spaces/<space>/wikis/<slug>/grants.yaml restricted sections, if any
spaces/<space>/shares.yamlThe output is deterministic - the same content exports to the same tree - so two archives can be diffed to see what actually changed.
Wikis come out with their shape. wikis/<slug>/wiki.yaml holds the wiki's own settings; pages.yaml holds the tree in order, each page with its path, its parent, whether it was a draft or published, and a pointer to the collections/ directory where its body, version history and feedback live; grants.yaml records who a restricted section was opened to.
Page content deliberately stays under collections/ rather than being copied into wikis/ - a page is a collection, so it already has its versions and its revision-pinned comments there, and duplicating it would mean two copies to keep in step. The wiki section is the map.
What's in it, and what isn't
Included: memories (including private ones and private projects), published collections and every artifact version, comments and approvals pinned to their versions, tag definitions with their privacy and members, notification rules, and share references.
Excluded by design:
- embeddings and search indexes - regenerable, and not your data in any meaningful sense,
- share codes, API tokens and notification secrets - a backup shouldn't be a credential store,
- inbox items and read cursors,
- entitlements and billing,
- auth identities. People appear as references, never as accounts.
It's an admin surface
An export dumps everything in the workspace, including content members kept private. That's what makes it a real backup, and it's why it's restricted to owners and admins, and audit-logged - the same posture as oversight.
Taking one
Settings -> Backups. Request an export, watch it build, download the archive when it's ready. Past exports are listed there.
You can also set a schedule - daily or weekly, with a retention count so old archives are pruned rather than accumulating forever. Set it once and the workspace backs itself up.
Export isn't an MCP tool - it's a human governance surface, so it's the app or the CLI, not something an instance does on your behalf:
kythe export --archive ./workspace.tar.gz
kythe export --out ./workspace-dir/Getting it back in
The archive isn't just readable, it's restorable. Ids and timestamps are preserved on the way back in, so citations and links keep working - it's a genuine round trip rather than a one-way dump. See Importing.
Your own data, as a person
Separately from the workspace export, you can export your own data from your profile page - the personal-data request, rather than the workspace backup. See Your account.