Does self-hosted Payload cost less than Sanity for your team?
If your Sanity renewal has come in higher than expected, the first thing to know is that Payload is MIT licensed, so the software license line on the Payload side is zero. That does not make self-hosting cheaper by default. The Sanity bill covers hosting of the Content Lake, its APIs and the operations behind them. When you run Payload yourself, those costs move to your side of the ledger: the database, object storage and CDN, hosting for the Next.js application that Payload installs into, upgrades, support and the internal engineering time to keep all of it running.
No supplied figure gives a price for either side, so this page does not state one. The outcome depends on your seat count, how much content and how many assets you store, how many API requests and page views your sites generate, and how many engineers you can dedicate to the platform. Ask Sanity for a written breakdown of what your current plan includes for seats, document and request volume, asset storage and any add-ons, and ask the same question of your implementation partner for each Payload cost component. Compare both in the same currency, for the same period, with the same traffic assumptions.
Plan for two costs that recur only on the self-hosted side and one that does not. The recurring costs are infrastructure and internal upkeep: someone must own database backups, Next.js hosting, security patches and Payload version upgrades. The one-time cost is the migration itself, which covers rewriting Studio schemas as Payload collections, converting content and loading the exported dataset. Confirm with your partner whether the migration is fixed-scope, and ask how your current Sanity document history and assets will be carried across, because that work drives the one-time figure more than any licensing decision.
Which cost components change when you move from Sanity to Payload
This table compares each cost component on the Sanity side with its self-hosted Payload counterpart and marks whether it is one-time or recurring. Sanity's plan figures are not reproduced here, so use your own invoices and written quotes to fill in amounts. The main takeaway is that the self-hosted route moves spend from a vendor bill to infrastructure, labor and upkeep that you control.
| Cost component | Sanity (hosted) | Self-hosted Payload | One-time or recurring |
|---|---|---|---|
| License or subscription | Sanity plan subscription; Studio code is MIT but content runs on hosted Content Lake | Payload is MIT licensed, so no license fee; confirm any paid add-ons you plan to use | Recurring on Sanity; none for the core Payload license |
| Seats | Editor and developer seats priced by plan; confirm current seat terms with Sanity | No per-seat license fee; user accounts are managed in Payload's built-in authentication | Recurring on Sanity; not charged per seat in Payload |
| Content and API usage | Document, request and bandwidth limits by plan; check your plan's limits and overage terms | Limits set by your database size, app capacity and caching design | Recurring on Sanity; capacity cost recurring on your side |
| Database | Included in the hosted Content Lake | MongoDB, PostgreSQL or SQLite you run, back up and patch; ask your DBA team for sizing | Recurring hosting; setup is one-time |
| Object storage and CDN | Asset storage and delivery included in plan terms; confirm asset limits | Your bucket and CDN, such as Cloudflare R2 when deployed there; billed by your provider | Recurring, usage-driven |
| Hosting the Next.js app | Studio hosted or deployed by your team; Content Lake not hosted by you | Payload installs into a Next.js /app folder and can run on Vercel, Cloudflare Workers or your own servers | Recurring compute; choose the host per your policy |
| Implementation | Schema and frontend work in Studio and your framework | Rewriting Studio schemas as Payload collections, access rules and frontend integration | One-time, scope-dependent |
| One-time migration | Dataset export as a tarball with documents, history and assets | Mapping documents, converting rich text to Lexical, importing assets, preserving drafts | One-time, driven by content volume and model complexity |
| Support | Included per plan or purchased separately; confirm terms with Sanity | Community channels or a paid retainer with an implementation partner; quote from written scope | Recurring if you buy retainers |
| Upgrades and testing | Handled by Sanity for Content Lake; Studio upgrades remain your code changes | Your team or a partner applies Payload releases, such as the v3 and v4 beta lines, and retests | Recurring; scales with release cadence |
| Internal skills | Teams already familiar with Sanity Studio and GROQ-based queries | Needs Next.js, database and infrastructure skills on your team | Recurring staffing or retained support |
What moves the Sanity versus Payload comparison
Sanity's cost is metered by seats, documents, API requests and assets, while a self-hosted Payload bill is driven by the infrastructure you run and the people who run it. The drivers below pull the two sides in different directions, so each one should be priced against your own usage rather than a generic comparison.
Editors and seats
Sanity charges by the people who log into the hosted Studio and collaborate in it, so every added editor, reviewer or contractor adds a recurring line item. With Payload, the admin panel is part of the application you host, so editor count changes the auth and access configuration rather than a per-seat invoice. Ask the vendor how seats are counted, whether viewers and API-only users are included, and what a mid-term increase costs. Count your real editors across both sides before comparing.
Document and request volume
Sanity plan limits tie cost to documents, API requests and bandwidth, so a busy site that publishes often or is read heavily can move into a higher tier. With self-hosted Payload, request volume lands on your Next.js hosting and database capacity, which you can scale in steps you control. Model your publish frequency, read traffic from front ends and any scheduled jobs. Ask Sanity exactly which request types count toward the limit.
Asset storage and delivery traffic
Images, video and files are often the largest and least predictable line in a headless CMS bill. On Sanity, storage and delivery are metered by the hosted platform. On Payload, you pick object storage and a CDN, such as an S3-compatible store, and pay the provider directly for storage and egress. Estimate asset count, average file size and monthly downloads, then check how each provider prices egress. The per-GB rates are yours to confirm with each provider.
Availability and on-call needs
Sanity operates the Content Lake, so uptime of the content store is the vendor's responsibility under its terms. A self-hosted Payload stack puts the database, Next.js runtime, backups and failover on your team or your provider. Decide how many hours of editor and publishing downtime the business can accept, who gets paged for a failed deploy, and whether you need a managed database with point-in-time recovery. Those decisions set the recurring operations cost more than any license line does.
Add-ons and collaboration history
Real-time collaboration, extended document history and longer retention are often sold as plan features on hosted CMSs. Confirm which of these you actually use, because Payload's built-in versions and drafts, hooks and live preview cover many editorial needs without an add-on, while the audit depth you need may still require extra logging or a database backup policy. Write down each feature your editors rely on and check whether it is included, a paid add-on, or something you would build.
In-house Next.js and database skills
Payload installs into a Next.js /app folder and runs on MongoDB, PostgreSQL or SQLite, so the people who maintain it need TypeScript, Next.js and database administration skills. Sanity removes most of that operating work from your team but leaves you dependent on its schema tooling and hosted service. If those skills are scarce, the cost of hiring, training or retaining engineers, or paying a partner for upgrades and support, belongs in the comparison. Ask for a written scope that names who handles upgrades, such as the move to Payload v4.0.0 once it is stable.
What running Payload on your own infrastructure includes
Payload installs directly into a Next.js /app folder, so the CMS and your front end ship as one application. It supports MongoDB, PostgreSQL and SQLite, and that database choice sets your first recurring line item. A managed PostgreSQL service, a self-run database on your own virtual machines, and a MongoDB deployment each carry different fees, backup responsibilities and patching work. Before comparing numbers, ask each provider what it charges for storage, backups, point-in-time recovery and cross-zone replication, and who applies database security patches.
Uploaded media and built assets need object storage and a CDN, which Sanity's hosted asset pipeline currently covers for you. Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere, and each path bills differently. Vercel and Cloudflare meter function execution, bandwidth, storage operations or request volume, and their plan limits change over time, so confirm current rates and included quotas in writing. A self-hosted option moves those costs onto your own compute, network egress and staff time. Map each asset request path, including image transforms if you use them, to a named charge.
Hosting the Next.js application is the line item teams most often underestimate. You will pay for build minutes, preview environments, staging copies, and the server or serverless capacity that renders editorial pages and runs the Payload admin panel. Upgrades add recurring effort: Payload's releases, including the v4.0.0 beta line, will need testing against your collections, hooks and access rules before rollout. Decide who owns that work, whether an internal team, a retainer or a fixed-scope engagement, and ask any partner to price upgrades, incident response and support separately from the one-time migration.
How to build a Sanity versus Payload cost model with your own numbers
This sequence turns vendor terms, your actual content volumes and your own cloud quotes into a side-by-side cost model that covers both one-time migration work and recurring operating costs over a fixed horizon.
Pull your current Sanity contract terms
Finance or procurement pulls the current Sanity agreement, order forms and invoices and lists every term that affects cost: plan tier, seat count and seat pricing, included document and API request allowances, overage rules, asset storage and bandwidth limits, and add-ons such as extra datasets, support tiers or security features. Ask your Sanity account team to confirm in writing any limit that is not stated in the contract. The step is done when each line item has a source document and an owner.
Measure real document, asset and request volumes
The platform team exports usage figures from the Sanity dashboard and, where needed, from the dataset itself. They record the number of documents by type, the number and total size of stored assets, monthly API requests split by published and draft reads, and the peak request rate from your front end. Count seats by role, separating editors who write from reviewers who only read. The output is a dated usage sheet with at least several months of history, so seasonal spikes are visible rather than averaged away.
Price Payload hosting from your own quotes
The platform team gets written quotes for the Payload runtime, a managed or self-run PostgreSQL or MongoDB database, object storage for uploaded media, a CDN for asset delivery, and hosting for the Next.js application. Payload runs on MongoDB, PostgreSQL or SQLite and can be self-hosted or deployed to platforms it documents, so confirm which database and host your team will use before pricing. Keep the figures in separate rows, because each one scales with a different driver. The step is done when every row has a quote, a unit basis and a source.
Add the cost of Payload's upgrade and support work
Engineering estimates the recurring work of keeping Payload current. Payload v3.91.0 was released on October 15, 2026, and a v4.0.0 beta line is in progress, with v4.0.0-beta.2 published on October 16, 2026, so plan upgrade work against the current release line and track the beta for breaking changes. Include dependency updates for Next.js, security patch review, test runs and any paid support or retainer you choose. Ask your implementation partner to quote this as a recurring line with a stated scope. The output is an annual maintenance estimate tied to hours or a fixed retainer.
Estimate the one-time migration and parallel run
Map the work into one-time costs: exporting the dataset, rewriting Studio schemas as Payload collections, converting Portable Text to Lexical, loading documents and assets, rebuilding any Sanity-specific workflows, and testing. Then add the parallel-run period, when both systems serve content and editors check output. Sanity's export includes document history and asset files but skips assets that return 401, 403 or 404, so budget time to review those gaps. Ask two or three implementers for fixed-scope quotes against the same written scope, and record the assumptions behind each.
Add staffing and operating time for both paths
Count the internal time that does not appear on an invoice: editor retraining, developer hours for schema changes, on-call coverage for the self-hosted stack, backup testing, security patching, and access reviews. Price these against your loaded internal rates, and note which items stay the same under Sanity and which move to your team. The output is a yearly staffing line for each option, so a reader can see where the self-hosted total depends on people rather than infrastructure.
Compare totals over a fixed horizon
Choose a fixed horizon, such as three or five years, and agree on it before any figures are entered. Add the one-time migration and parallel-run costs in the first year, then add each recurring line year by year for both paths, including Sanity seat and overage growth at your measured rate of change. Run a sensitivity check on the three inputs most likely to move: seat count, asset volume and request volume. The step is done when the sheet shows annual and cumulative totals for both options and the assumptions behind each cell are written next to it.
What the one-time migration effort covers
The migration starts with a full copy of the dataset. The sanity dataset export command writes a gzipped tarball that contains the documents, their history and the asset files, so the tarball is the input to every later step. Before you run it, check the export against the rule that the command skips assets returning 401, 403 or 404. Any skipped file is content you will not get back from the export, so list the missing assets now and decide whether to re-fetch them from their sources or accept the loss. Confirm the export's exact behavior with the Sanity CLI reference for dataset commands and with your own dataset before you plan around it.
The largest engineering task is rewriting Studio schemas as Payload collections, globals and fields. Each Studio document type, object type and reference needs a collection or field definition, and Portable Text content must be converted to the Lexical rich text format that Payload uses. Drafts are a specific risk: Payload's versions and drafts feature has its own data model, so decide early whether you need the full edit history from the tarball or only the current draft and published state. Then load documents and assets through the Payload API or a script, and check reference integrity, locales and any custom Studio plugins that stored data outside standard fields.
The effort scales mainly with schema complexity, the number of document types and custom components, the volume of Portable Text with embedded objects, and the number and size of assets. Run a short inventory before you request a quote: count document types, list custom input components and plugins, sample documents with nested references, and count assets with their total size. Ask any implementation partner to price the schema mapping, the Portable Text conversion, the asset load and the verification pass as separate line items, and to state which of them are one-time and which recur. Treat those figures as estimates until your inventory confirms them.
Questions buyers ask before comparing Sanity and Payload costs
How much effort does a Sanity to Payload migration take, and what drives it?
The effort depends mainly on how many document types, references and custom Studio components you have, how much Portable Text you store, and how many assets must move. Each Studio schema has to be rewritten as a Payload collection or global, and rich text has to be converted to Lexical. Teams with a small, well-defined schema and a clean export usually have less to rebuild than teams with heavily customized editing views, plugins or deep reference graphs. Ask any partner to inventory these items before quoting, because the inventory is what turns a vague estimate into a scope.
Can our own team do the Sanity to Payload migration without outside help?
A team with strong TypeScript and Next.js experience can do it internally, particularly if the content model is modest. The export is available through the Sanity CLI, which produces a gzipped tarball with documents, history and asset files, so the raw data is accessible without a Sanity contract change. The harder parts are mapping references, converting rich text, reproducing drafts and preserving history, and validating the result against editor expectations. Outside help is most useful when the timeline is fixed, when compliance evidence is needed for the migration itself, or when the team has no capacity to run a parallel environment.
What does the migration need from engineers and editors?
Engineers need to rewrite schemas in code, build the Payload configuration, set up the Next.js front end or adapt existing rendering, write import scripts for documents and assets, and configure access control. Editors need to review the migrated content, confirm that drafts, references and media look correct, and test their daily workflows in the new admin panel. Both groups should agree early on what counts as a successful cutover, because editors often notice differences in preview, scheduling or collaboration that engineers do not. Plan for editor testing as a separate workstream with its own time.
How long does a Sanity to Payload migration take?
The timeline is set by the size of the content model, the volume of assets, the amount of front-end work, and how much parallel running the business accepts. Work usually runs in phases: export and inventory, schema rebuild, data import, front-end integration, editor testing and cutover. Each phase can expand if the inventory reveals undocumented fields or custom Studio logic. No duration is given here because none is supplied for this comparison; ask for a phased plan with dependencies in any written scope.
Does Payload's MIT license mean there is no license fee?
Payload's code is MIT licensed, so there is no per-seat or per-request license fee for the software itself. You still pay for the infrastructure it runs on: a database such as MongoDB, PostgreSQL or SQLite, object storage for assets, a CDN, and compute for the Next.js application. Those costs recur monthly or annually and scale with traffic and content volume. Hosting choices also matter: Payload documents deployment to Vercel, to Cloudflare Workers with R2 and D1, or self-hosting, and each option has its own bill. Compare the total of these components with your current Sanity invoice, not the license line alone.
How are Payload upgrades handled, and who is responsible for them?
Payload publishes versioned releases on its GitHub releases page, and the project is actively developed. For example, v3.91.0 was released on October 15, 2026, and a v4.0.0 beta line is in progress. Upgrades are your responsibility when you self-host, so you need a process for reading release notes, testing against your schema and custom code, and deploying. Ask whether the upgrade work will be part of a retainer, handled by your team, or both, and confirm how breaking changes between major versions will be tested before they reach production.
What ongoing support and operations work comes after launch?
After launch you carry the work Sanity currently handles: uptime of the application and database, backups, security patches for dependencies, monitoring, capacity planning for assets, and incident response. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and it can plan and implement those controls inside your own cloud account or data center. Confirm in writing who answers pages at night, what response expectations apply, and how restores are tested, because these items recur for as long as you run the platform.
Why the Studio license does not remove the content cost
The MIT license on Sanity Studio covers the editing interface, not the place where your content lives. According to Sanity's GitHub repository, Studio is MIT licensed, but content is stored in Content Lake, a real-time data store hosted by Sanity. That means the Studio code you deploy to your own hosting does not carry your documents, document history or assets with it. Your recurring Sanity bill still pays for storing and serving the content, and the plan terms you signed decide how much of that you can use, how long history is retained and what happens to your data when you leave. Before you model a self-hosted Studio as a cost saving, separate the three line items: Studio hosting, Content Lake usage and the exit effort.
Payload takes the opposite position on where the data sits. Payload is MIT licensed and supports self-hosted MongoDB and PostgreSQL databases, so the documents, versions and media metadata live in a database you provision and back up. The recurring costs move to components your team already buys or runs, such as database hosting, object storage and the Next.js hosting, and they can be compared line by line in a quote. The trade-off is that you now own backups, restores and capacity planning for that database from day one. Before you rely on either path, ask Sanity in writing which terms govern export of your own data, including the document history and asset files that the dataset export includes, and whether any plan restricts that export. Confirm the same for any Content Lake retention limits. The answers determine whether your exit cost is a scripted export or a negotiated project, and that single fact can change the cost comparison more than the Studio license does.
How DeployOpen scopes a fixed-price Payload implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts or data centers. For a Sanity to Payload move, we start with a written scope that separates the one-time migration from the recurring infrastructure you will run.
How we scope
- We record your current Sanity seats, plan limits, add-ons and dataset sizes so the cost comparison uses your numbers.
- The written scope lists which Payload collections, databases, hosting targets and integrations are in and out of the engagement.
- We agree deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
- Ongoing support, upgrades and continuous testing can be added as a retainer once the scope is signed.
How we build
- We install Payload into your Next.js app and choose PostgreSQL or MongoDB based on your existing database standards.
- We size the object storage, CDN and Next.js hosting choices against your asset volume and traffic profile.
- We rebuild Sanity schemas as Payload collections, then test field access control, drafts and localization.
- We run security testing on the admin panel, APIs and access rules before content editors start working in it.
How we hand over
- We document the database, storage, deployment and backup setup so your platform team can operate it.
- We deliver a migration report that lists exported documents, assets skipped during export and items needing manual review.
- We provide a configuration record for upgrades, including how Payload release changes will be reviewed in your environment.
- We prepare the controls and evidence that your compliance assessors may ask for, without issuing any certification.
How we support
- Support terms follow the signed scope, and any retainer is priced separately from the implementation.
- Upgrades to new Payload releases are planned, tested in a staging copy and then applied to production.
- Backups and restore tests are documented so you know how content is recovered after an incident.
- Ask us to confirm response expectations and ownership of each component in writing before you sign.
