Can you self-host Sanity, or only its Studio?
If your requirement is that customer content must sit in a region you choose, inside your own cloud account or an air-gapped network, you need to know that self-hosting Sanity only covers the editing interface. Sanity Studio, the editor, is MIT licensed, so you can build it and deploy it on your own infrastructure. Content, however, is stored in Content Lake, the real-time data store that Sanity hosts. A self-hosted Studio still reads and writes to Content Lake, so a data location requirement is not met by moving the editor alone.
Before you decide, confirm three things in writing with Sanity: where Content Lake datasets are hosted for your project, what contractual controls apply to that location, and whether any of your required data (documents, document history, assets and the metadata around them) can be held outside the hosted service. Use the sanity dataset export command from the Sanity CLI to see exactly what a dataset contains, including document history and asset files, and check which assets the export skips. That export is also the first artifact you will need if you plan an exit. Confirm the current export behavior against the Sanity CLI reference for datasets for your CLI version.
If residency, air-gap or exit requirements apply to the content itself, the full self-hosting path means moving content out of Content Lake into a CMS whose database you control. Payload and Strapi are the two options in this group that fit that case. Payload runs in your Next.js app on a database you operate, and Strapi runs on PostgreSQL, MySQL, MariaDB or SQLite. Each has different licensing, hosting and migration work, which the sections that follow compare.
What a residency or exit constraint requires from the content store
A residency or exit requirement applies to every place content lives: the documents, the version history and the asset files. For a Sanity project, the Studio can run on your infrastructure, but the data store behind it is the part to answer for, and each card below is a question your team must settle before choosing a path.
Where does the live content store sit?
Sanity Studio is MIT licensed and can be deployed on your own hosting, but documents are saved to Content Lake, a real-time data store that Sanity hosts. Self-hosting the Studio therefore leaves the primary copy of your content in Sanity's environment. Ask whether your residency rule covers the editing interface only or the stored documents too, and document the answer for your assessor.
Does the export carry version history?
The sanity dataset export writes a local gzipped tarball that includes document history, not only the current version of each document. If your retention or audit rules require past revisions, confirm that the history in the tarball meets them before you rely on it. Check how far back your dataset history goes and whether your plan limits it.
Which assets will be missing?
The export skips any asset file that returns a 401, 403 or 404 response when the tool requests it. Images or files that were deleted, moved or access-restricted can therefore be absent from the tarball even though their document references remain. Run a list of asset references against the export and record every skipped file as a known gap before you sign off on an exit.
Can you export on demand and at scale?
An exit plan needs a repeatable export, not a single snapshot taken on the day you leave. Confirm who on your team holds the credentials and permissions that run the CLI, how long a full export takes for your largest dataset, and whether you can run it into storage you control. Write the export into your runbook and test it against a copy.
Where do the exported files go?
Once exported, the tarball contains documents and asset files that are now copies of regulated data. Decide where it lands, who can read it, how long it is kept and how it is encrypted, so the exported copy meets the same residency rule as the original. Treat the export as sensitive data with its own access log and retention schedule.
Who must rebuild what the export leaves out?
The export gives you documents, history and assets, but the schemas, access rules, webhooks and query logic that run your site live in your Studio code and Sanity project settings. Those must be rebuilt in the target platform, such as Payload or Strapi, before the cutover. List each dependency now so the rebuild scope is known before you choose a destination.
What self-hosting the Studio does and does not change
Self-hosting the Studio moves the editing interface, not the content. Sanity Studio, the React application editors use to create and edit documents, is MIT licensed, so you can build it and serve it from your own hosting. Your schemas stay in code and the Studio itself has no license fee. Content Lake is a different component: it is the real-time data store where documents, document history and assets live, and Sanity runs it as a hosted service. Deploying the Studio on your own infrastructure changes where the editor's JavaScript is served from, and nothing else about where the data sits.
In practice, every save, publish, query and asset upload still goes to Content Lake through your project ID and dataset. Real-time collaboration, where several editors see each other's changes live, runs on that same hosted backend, so it does not move with the Studio. Content delivery to your front end also depends on the hosted API, including its CDN and its plan limits. Before you commit to a Studio-only deployment, confirm with Sanity which parts of the Studio's behavior depend on hosted services in your plan, and which hosting and access terms apply to your datasets.
If residency, exit or continuity is the driver, the question is whether the documents themselves must leave Content Lake. The sanity dataset export command gives you a local copy of a dataset, including document history and asset files, so you hold an archive you control. That archive is not a running system, though: you will still need a database, asset storage and an API to serve content, and that is where a platform such as Payload or Strapi comes in. Decide early which of these you need, and ask Sanity for written terms on data location, retention and export before you rely on either path.
Which open-source platforms can hold the content itself
This table compares the self-hosted platforms that can store the content itself once it leaves Content Lake, focusing on licensing, database support and the residency questions each one raises. Read each row as a checklist: the license and database columns answer what you can run inside your own boundary, and the confirm column lists what to verify before you commit.
| Platform | Residency fit and licensing | Trade-offs | What to confirm with the vendor |
|---|---|---|---|
| Payload | MIT licensed. Supports self-hosted MongoDB and PostgreSQL, so content can stay in a database you operate. | Code-defined collections run inside a Next.js app, so your team owns the app, hosting and upgrades. | Confirm the database version support for your chosen engine and how Payload v4 beta changes are scheduled. |
| Strapi | Community Edition is MIT. Code under ee directories falls under the Enterprise license unless you hold a signed agreement. | Strapi 5 supports PostgreSQL, MySQL, MariaDB and SQLite but not MongoDB, so a MongoDB-based export needs a relational target. | Confirm which features you need sit in ee directories, such as SSO and audit logs, and whether a Growth or Enterprise plan is required. |
| Wagtail | BSD-3-Clause licensed Django CMS that runs on your own PostgreSQL database. | Suits teams already operating Django. Structured content maps well, but editors work in a page-tree model. | Confirm commercial support terms with Torchbox if you need a contracted service level. |
| Directus | Uses the Monospace Sustainable Core License, which allows internal use and bars competing use. It is not OSI open source. | Database-first model gives direct SQL access to content, but the license needs legal review for your use case. | Confirm with Directus whether your internal, customer-facing or partner use is permitted under the license terms. |
How to deploy a self-hosted content store under a residency constraint
This sequence moves a Sanity dataset into a database and app you control, inside the region or network your residency rules require, and ends with editors and readers working against the new store. Each step has a check that tells you it is safe to move on.
Confirm the residency and network scope
Compliance, legal and the platform owner agree in writing which regions, cloud accounts, data centers or private networks may hold content, backups, asset files and logs. Also agree who may access the Studio and the delivery API. The output is a short scope note that names the target location and the owners of each system. Do not start the export until this note is signed off, because it decides where every later step runs.
Export the dataset with history and assets
An engineer with the right Sanity project permissions runs the Sanity CLI dataset export command for the production dataset, which writes a gzipped tarball that includes document history and asset files. The engineer stores the file in the approved location and records its checksum. The step is complete when the tarball opens, the document count matches what the team expects from the Studio, and the checksum is in the migration log.
Record skipped assets
The export skips any asset that returns a 401, 403 or 404 response, so the engineer reviews the export log and lists every skipped file with its document reference. Content owners then decide whether each file must be re-uploaded from original sources, replaced or retired. The output is a tracked list of missing assets with an owner for each one. Without this list, broken images and files can appear after cutover without anyone noticing.
Stand up the database and application in scope
The platform team deploys the chosen target, such as Payload on PostgreSQL or Strapi on PostgreSQL, inside the approved region or network, with object storage for assets in the same boundary. They set up backups, encryption, access logging and administrator single sign-on according to the scope note. The step is done when the empty application starts, its database is reachable only from approved networks, and a restore test of an empty backup has succeeded.
Rebuild schemas and content types
Developers translate the Sanity document types from the Studio schema into the target's collections or content types, including references, localization and rich text conversion. They keep the mapping in version control so reviewers can compare each field against the original. The step is complete when a test import of a small sample of documents shows every field populated, references resolving and rich text rendering as expected.
Load content and assets into the new store
The team imports the documents and assets from the tarball into a staging copy of the target, then compares document counts, sample entries and asset links with the export log. Missing assets are handled from the list created earlier. The step is complete when the content owners sign off on a reconciliation report that explains every difference from the source dataset.
Cut over the Studio and delivery
The team points editors to the new administration interface, moves the front-end to read from the new delivery API, and sets Sanity read access to a read-only or retired state according to the exit plan. They keep the export tarball and the Sanity dataset until the owners agree they are no longer needed. The output is a documented cutover record showing who approved the change, what changed and how to roll back if the new store fails.
Questions buyers ask before hiring help
Does self-hosting Sanity Studio satisfy a data residency requirement?
No, not on its own. Sanity Studio is MIT licensed and can be deployed on your own hosting, but the documents, history and assets it edits are stored in Content Lake, which Sanity hosts. Hosting the Studio in your region moves the editing interface, not the content. If residency applies to the content, the data store must move, which means a self-hosted CMS with its own database. Confirm with your compliance lead which data classes fall under the requirement, then map each one to where it is stored today.
What does moving Sanity content to Payload or Strapi involve?
The work has four main parts: rebuilding the content model as collections or content types, converting Portable Text into the target editor's rich text format, loading documents and assets from the export, and checking that drafts, references and history survive the move. Sanity's dataset export produces a gzipped tarball with documents, history and asset files, but it skips assets that return 401, 403 or 404 responses, so those gaps need a list before cutover. Payload installs into a Next.js /app folder and supports MongoDB, PostgreSQL and SQLite. Strapi 5 supports PostgreSQL, MySQL, MariaDB and SQLite, not MongoDB.
What does our team have to provide during a migration?
Expect to supply people who know the content model and the business rules behind it. Engineers must own the front-end that reads the content, because both targets change how APIs and output are delivered. Editors need to test drafts, references and publishing workflows against the new system. Operations staff must agree on where the database, object storage and hosting will run. Ask any implementation partner to list these roles in the written scope, with the owner and the hours each role is expected to give.
Can our in-house team do the migration without outside help?
Often yes, if the content model is small, the team has run a Node.js application in production, and someone can own the cutover. The risk concentrates in three places: converting rich text and references without losing meaning, handling assets that the export does not return, and keeping published content consistent during the switch. Teams that lack Node.js, database or migration experience usually plan for a fixed-scope engagement for those parts. DeployOpen plans, implements and hardens self-hosted platforms in the client's own environment, and scope is agreed in writing before work starts.
How do Strapi's Enterprise features affect the choice?
Strapi is open core. The Community Edition is MIT licensed, but code in ee/ directories falls under the Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Per Strapi's self-hosted pricing page, SSO is an add-on for Growth and included in Enterprise, while audit logs and review workflows are Enterprise features. Strapi SSO covers administrator login only, and end-user login is handled by the Users and Permissions plugin. Before choosing Strapi, list which of these features you need and confirm the license terms with Strapi.
What drives the cost of a self-hosted replacement?
Cost falls into one-time work and recurring running costs. One-time costs are the migration itself, schema rebuilding, front-end changes and testing. Recurring costs include hosting for the application, a PostgreSQL or other supported database, object storage for assets, backups, upgrades and support. Strapi's self-hosted pricing page lists Growth at 45 US dollars per month including 3 users, plus 15 dollars per extra user, and Enterprise at custom pricing, which applies only if you need its features. Payload and Strapi Community have no listed seat fee on those pages, so compare the infrastructure and labor lines. Ask any quote to separate migration, infrastructure and support.
Is the Strapi v4 to v5 upgrade relevant if we start on Strapi?
It matters if a team starts from an older Strapi project. Strapi v4 reached end of life on April 30, 2026, and its final release, 4.26.2, will receive no further updates. Strapi's v4 to v5 migration docs describe an upgrade tool with codemods, data migration scripts that run on first start of Strapi 5, and a breaking changes list. The docs say to back up the database first, because downgrading is not supported. Confirm your current version and plan the upgrade before you build new work on top of it.
Evidence to keep for a residency review
A residency review asks where content lives, who can reach it and what was left behind during a move. The cards below list the artifacts that answer those questions for a Sanity dataset that is exported and moved into a database and object storage you control. Independent auditors decide whether any of this conforms to a requirement.
Export run log
Keep the full console output and the command used for each sanity dataset export run, along with the date, the dataset name, the Sanity project ID and the operator. The export produces a gzipped tarball that includes document history and asset files, so the log proves which dataset state was captured and when. Hash the tarball immediately and store the hash with the log so a later reviewer can confirm the file was not changed.
Record of skipped assets
The export skips any asset that returns a 401, 403 or 404 response. Build a register that lists each skipped asset by its document reference, its URL and the response code, and assign an owner to decide whether the file is recovered, replaced or retired. An auditor will treat an unexplained gap in the asset set as missing data, so the register should be signed off before cutover.
Data location documentation
Document the region, cloud account, data center or network where the new database and object storage run, and where backups are kept. For a Payload or Strapi target, this covers the PostgreSQL or other supported database host, the asset bucket and any CDN or edge cache that holds copies of files. Confirm with your cloud or hosting provider which regions their backup and replication features use, since defaults can move copies outside the primary region.
Access control configuration
Export the access settings for the Studio, the new CMS admin panel, the database accounts and the storage buckets. Sanity project members and roles are managed in Sanity and will not carry over to the new platform, so record who held editor, admin and API token access before the move and map each to a role in the target system. Keep the configuration as code or as dated screenshots, and note which accounts were removed after cutover.
License review for each component
List every component that will run the content, including the Studio, the CMS, its database driver, the Node.js runtime and any plugins. For Strapi, check which code sits under the ee directories and whether a signed agreement or a Strapi Cloud subscription covers it. Record the license name and the date of review, because an auditor will ask whether each component can be used for the way your organization runs it.
Hosted Content Lake retirement record
Record the date on which the Sanity dataset was frozen, the date the new system became the system of record and the date the hosted dataset was deleted or set to read-only. The Studio can still be deployed on your own hosting, but the content stored in Content Lake is the part a residency reviewer will ask about. Keep the vendor's confirmation of deletion, or the written steps you took, with the cutover plan.
When residency or exit needs justify moving the content
Keep Sanity when the only thing you need to control is the editing tool. Sanity Studio is MIT licensed, so you can host the editor on your own infrastructure, change its schemas and keep the code in your repository. Move the content itself when the documents, assets or history must stay inside your environment, or when the risk of being unable to leave Content Lake is too high for your board or regulator. Those two triggers are different. A Studio you host yourself still reads and writes to Sanity's hosted datastore, so a residency rule that covers stored personal data is not met by hosting the front end alone. Check with your data protection lead which data classes fall under the rule, and whether the rule covers the document history that the dataset export includes.
Before committing to a move, test exit readiness. Run sanity dataset export against a non-production dataset and confirm the tarball holds the documents, history and assets you expect. Then check which assets were skipped, since the export omits files that return 401, 403 or 404 responses. A move to Payload or Strapi takes the content out of Content Lake, so you then own the database, backups and upgrades. Strapi is a useful reminder of that cost. Its v4 line reached end of life on April 30, 2026, and its final release, 4.26.2, will receive no further updates. Plan a recurring upgrade calendar, a tested database backup before each change and an owner for security patches from the first day, whichever platform you choose.
How DeployOpen deploys a self-hosted content store
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Sanity move, that means first confirming what you actually need to host, whether the Studio alone or the content store, before any build starts.
How we scope
- We confirm whether you need the Studio hosted, the content moved, or both, before defining any work.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory dataset size, asset volume, document types, roles and integrations that depend on the Content Lake API.
How we build
- We stand up the chosen target, such as Payload or Strapi, in your environment with your database and object storage.
- We rebuild schemas, rich text handling and asset import, then test loaded documents against the original export.
- We run security testing on the admin panel, APIs and access rules before the content store goes live.
How we hand over
- You receive documentation covering the deployed architecture, configuration, backup procedure and rollback steps.
- We walk your team through editor workflows, publishing, drafts and history so ownership moves with the system.
- Compliance evidence is prepared for your assessor, though DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover platform upgrades, backup verification and restore tests on your schedule.
- Ask us to confirm in writing which upgrade, hosting and support responsibilities sit with you versus DeployOpen.
