When Strapi Cloud fits and when self-hosted Strapi fits
Strapi Cloud suits a team that wants Strapi run for it and can live with a fixed hosting region, the plan allowances and a narrower backup scope. Self-hosting suits a team that needs to control where data sits, how and what gets backed up, which database engine runs underneath, and how administrators sign in. Start with three constraints before comparing prices. First, confirm the hosting region, because a Strapi Cloud project's region is set at creation and cannot be changed afterwards. Second, check whether your data residency rules or recovery objectives depend on assets and secondary environments, since Strapi Cloud backups cover only the production database. Third, list the monthly API request, asset storage and bandwidth your traffic and media library will realistically need, and compare that with the Starter, Pro and Business allowances.
The cost picture differs in shape. Strapi Cloud is priced per project per month, so the recurring fee grows with each project and each tier you need, and extra API requests are billed in blocks. Self-hosting shifts the spend to your own cloud accounts, your platform team's time and any Growth or Enterprise licenses you add for SSO, audit logs or review workflows. Those license features matter most in regulated environments where administrator access must run through your identity provider. Ask Strapi to confirm the current Cloud plan terms, and ask your own platform team to estimate the operating hours for patching, backups, restores and Node.js and database upgrades. Those are one-time setup costs plus recurring operating costs, and they are often the largest line item.
Choose Strapi Cloud if your priority is a managed PostgreSQL database that Strapi operates and your recovery plan can rely on its daily or weekly production-database backups. Choose self-hosted Strapi if you must use an external SQL database under your own support and security model, which Strapi says it cannot secure or support, or if you need a backup scope that includes uploaded assets and every environment. Where either path is uncertain, confirm the external database, backup and region questions in writing before you commit, and keep a tested restore procedure for whichever option you pick.
How Strapi Cloud and self-hosted Strapi compare on facts
This table sets Strapi Cloud's per-project plans and backup rules beside Strapi's self-hosted licensing, seat pricing, SSO scope and version support. Read each row as a question to answer for your own project, then confirm the items marked for confirmation before you commit. The main takeaway is that Cloud trades infrastructure work for fixed per-project limits, while self-hosting keeps data location and database choice in your hands but moves backups, uptime and upgrades onto your team.
| Factor | Strapi Cloud | Self-hosted Strapi |
|---|---|---|
| Starting price | Starter 35, Pro 90 and Business 450 US dollars per project per month (Strapi Cloud pricing page) | Community is free with unlimited users; Growth lists at 45 US dollars per month including 3 users (Strapi self-hosted pricing page) |
| Usage allowances | 100,000, 1,000,000 and 10,000,000 monthly API requests on Starter, Pro and Business; extra requests 1.50 US dollars per 25,000 | Unlimited entries and API calls on all self-hosted plans; infrastructure capacity is your cost to size |
| Seat pricing | Priced per project, not per editor; confirm whether seat limits apply to your plan tier | Community has unlimited users; Growth adds 15 US dollars per extra user beyond 3; Enterprise is custom |
| Backups | Pro weekly and Business daily, 28-day retention; Starter has none. Database of production only, not assets or secondary environments | No vendor backups; you design and test database and asset backups in your own environment |
| Hosting region | Set at project creation and cannot be changed afterwards | Chosen by you across your cloud accounts, data centers or private networks |
| Database options | Pre-configured PostgreSQL; an external SQL database is possible but Strapi warns of unexpected behavior and gives no security or support for it | MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 14 or later and SQLite 3 for Strapi 5; no MongoDB or other NoSQL |
| License terms | Hosted service; the platform is open source but operated by Strapi | Code outside ee directories under MIT Expat; ee directories under a proprietary Enterprise license |
| SSO scope | Confirm SSO availability and plan requirements in the current Strapi Cloud documentation | SSO is an add-on for Growth and included in Enterprise; covers administrator login to the admin panel only, not end-user login |
| Node.js and Strapi 5 support | Confirm the Node.js and Strapi versions run on each project before adopting an upgrade | Runs only on Active or Maintenance LTS Node.js versions; Strapi 5.58.0 released October 14, 2026; Strapi v4 reached end of life April 30, 2026 |
Where your data lives and who can reach it
Strapi Cloud and self-hosting put your data under different owners, locations and access paths. The cards below cover where data sits, what is backed up, how administrators and end users sign in, and what evidence you must gather yourself.
Region is fixed at creation
On Strapi Cloud, a project's hosting region is set when the project is created and cannot be changed afterwards. If residency rules name specific jurisdictions, confirm the available regions with Strapi before you create the project, because moving later means building a new project and migrating content. Self-hosting lets you choose the cloud account, data center or air-gapped network yourself, and you can move it under your own change control. Ask Strapi which region options apply to your account.
Production-only database backups
Strapi Cloud backups cover only the production environment's database. Uploaded assets and secondary environments are not included, so a restore may bring back content records that point to media files no longer present. Business projects are backed up daily with 28-day retention, and Starter has no backups. Ask Strapi how asset recovery works, and plan your own copy of media and non-production data if recovery time or residency depends on them.
Uploaded assets sit outside the backup
Media uploads are a separate data set from the database and are excluded from Strapi Cloud backups. For regulated content such as scanned records or identity documents, this changes both your residency analysis and your recovery plan. Self-hosted teams choose where object storage lives and how it is replicated and backed up. Confirm with Strapi where assets are stored, how long they are retained, and whether any copy leaves your chosen region.
SSO covers administrators only
Strapi SSO applies to administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory. It does not authenticate end users of your applications, which the Users and Permissions plugin handles separately. Plan both paths, including how administrator access is granted and removed and whether local login is locked out. This applies whether you use Strapi Cloud or self-host, and it is available in the self-hosted Growth plan as an add-on or in Enterprise.
Secondary environments need their own controls
Secondary environments on Strapi Cloud fall outside the production-only backup scope, so data copied or created there may have no managed recovery point. Treat them as production-grade data when they hold real content or personal data. Restrict who can access them, confirm how they are provisioned and removed, and document their retention. Self-hosted staging and production are controlled by your own access and backup policies.
Evidence comes from you and the vendor
DeployOpen prepares controls, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Request current compliance reports and any security documentation directly from Strapi before you rely on them for a residency or assurance decision, and confirm what each covers for your plan. Your own access reviews, backup restore tests and region records still need to be produced.
What Strapi Cloud backs up and what it leaves out
Strapi Cloud backups cover the production database only, and the schedule depends on your plan. Pro projects get weekly backups, Business projects get daily backups with 28-day retention, and Starter projects get no backups at all. The backups do not include uploaded assets or secondary environments. A team on Starter therefore has no managed database recovery point, and a team on Pro or Business still has to plan for media files and any staging or preview environment it depends on. Before go-live, confirm which plan the project sits on, write down the recovery point you can accept for the database, and check where the files in the media library are stored and how you would restore them.
For a self-hosted Strapi, the same gaps belong to your team. You choose the PostgreSQL, MySQL, MariaDB or SQLite database, so you also choose the backup tool, schedule, retention and restore test, using the infrastructure you already run. Uploaded assets sit on the storage provider you configure, so the backup job must cover that bucket or volume as well as the database. Staging and preview environments are simply more deployments you back up or rebuild on purpose. The trade-off is that you control every recovery point and pay for the tooling and staff time, while Strapi Cloud removes that setup for the production database. Ask whether your plan would give you a point-in-time restore and how long a full restore takes, because the vendor's documentation does not answer those questions for every plan.
The hosting region is fixed when you create the project, and it cannot be changed afterwards. Choose the region with your data residency rules, your users' locations and your latency needs in mind before the first deployment. If the choice turns out to be wrong, the fix is a new project and a data migration, not a setting change. Add the region to your architecture review and sign-off checklist, and confirm it matches any contractual or regulatory statement about where content is processed and stored.
Managed PostgreSQL or an external database on Strapi Cloud
Strapi Cloud provides a pre-configured PostgreSQL database for each project, so the database engine is chosen for you and set up before your first deployment. Strapi operates the platform that hosts it, which means the day-to-day work of keeping the engine running sits with the vendor rather than with your team. Your team still owns the content model, the data it stores and the decisions about who can change production data.
- Engine choice: You do not select the database version or its configuration. Confirm the PostgreSQL version and any tuning options in the Strapi Cloud database documentation before you rely on specific behavior.
- Backups: Backups cover only the production environment's database. Uploaded assets and secondary environments are not included, so plan separate copies for media and for staging data.
- Recovery: Ask Strapi what restore options exist, how long a restore takes and who initiates it, and whether a restore can be tested in a non-production environment.
- Region: The hosting region is fixed at project creation, which determines where the database resides. Decide the region before you create the project.
- Support boundary: Keep the Strapi Cloud plan allowances in view, including storage and bandwidth limits, because they affect how much data and traffic the managed database serves.
Before you commit, confirm in writing what Strapi maintains, what your team must maintain, and how a restore is requested and verified.
Strapi Cloud can connect to an external SQL database instead of the pre-configured one. This gives you control over where data lives and which engine and configuration you run, but Strapi warns that an external database may cause unexpected behavior or performance issues. Strapi also states that it cannot provide security or support for an external database, so responsibility for its operation shifts toward your team and any database provider you use.
- Support gap: Strapi will not support the external database itself. When an issue traces back to the database, your team or its vendor must diagnose it.
- Security ownership: Patching, access control, encryption settings and network exposure of the external database become your responsibility.
- Performance risk: Strapi's warning covers performance, so load testing against realistic API traffic is necessary before production use.
- Backups: Strapi Cloud's backups apply to the pre-configured database. Confirm independently how the external database is backed up and restored.
- Compliance evidence: If an auditor asks who controls the database, the answer will be your team and your provider, so document that chain of responsibility.
Ask Strapi to confirm in writing which external database engines and versions are acceptable for your plan, and what escalation path exists when an issue involves the database.
When you self-host Strapi, you choose the database engine and its hosting. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and it does not support MongoDB or other NoSQL databases. Your team owns the database for its full lifecycle, which includes provisioning, tuning, patching, backup design and recovery testing.
- Tuning: Your team sets connection pooling, memory, indexing and replication to match your load and data volume.
- Patching: Your team applies engine updates on a schedule that fits your change process and confirms compatibility with the Strapi version you run.
- Recovery: You define backup frequency, retention, off-site copies and restore tests. Strapi's migration guidance tells you to back up the database before upgrades because downgrading is not supported.
- SQLite: Suitable for local development and very small deployments, but it adds operational limits that many production teams avoid. Verify fit with your load profile before choosing it.
- Engine choice: Pick the engine your operations staff already runs well, because that skill determines how reliably the database is maintained.
Before you choose an engine, confirm the supported versions for your Strapi release in the installation documentation and map each responsibility to a named owner.
What your team runs in each model
This table lists the day-to-day operations for Strapi Cloud and self-hosted Strapi, showing which tasks the vendor covers and which fall to your team. Read each row as a question to confirm in a quote or proof of concept, since the answer shapes staffing more than any license term.
| Operation | Strapi Cloud | Self-hosted Strapi |
|---|---|---|
| Hosting and infrastructure | Strapi runs the hosting for each project in the region chosen at project creation | Your team provisions, patches and monitors the servers or containers in your own cloud or data center |
| Node.js runtime updates | Strapi manages the runtime, so confirm which Node.js versions are in use and when they change | Your team must run only Active or Maintenance LTS Node.js versions and plan each runtime upgrade |
| Database operations | Pre-configured PostgreSQL is provided; an external SQL database is not supported or secured by Strapi | Your team selects, sizes, patches, tunes and restores MySQL, MariaDB, PostgreSQL or SQLite |
| Backups | Pro projects are backed up weekly and Business daily with 28-day retention; Starter has no backups; assets and secondary environments are excluded | Your team designs, schedules, encrypts, tests and stores backups of the database and the upload directory |
| Asset storage and bandwidth monitoring | Allowances are set per environment and per month; your team tracks usage against the plan limits | Your team sizes storage and bandwidth, watches growth and chooses where uploads are kept |
| Strapi 5 minor release upgrades | Confirm with Strapi how and when minor releases reach your project and what testing window you get | Your team tests each Strapi 5 minor release, such as recent weekly releases, and schedules the upgrade |
| SSO configuration for the admin panel | Confirm which SSO options and plan tier apply to your project before you commit | Your team configures the identity provider connection, default role and any local login lock-out |
| Security patching of the application | Strapi operates the platform; confirm patch timing and incident handling in writing | Your team applies patches, monitors advisories and runs the security testing you require |
How to move a project between Strapi Cloud and self-hosting
This sequence lets a team move a Strapi project in either direction with a verified database, its assets and secondary environment content accounted for, and a documented cutover. It is most useful when the move is planned before the team commits to a plan or hosting region.
Inventory plan, allowances and region
The platform or engineering lead records the current Strapi Cloud plan for the project, its monthly API request, asset storage and bandwidth usage, the environments in use, and the hosting region. Region is set at project creation and cannot be changed later, so the team confirms it now and notes it as a constraint on the target. The output is a written inventory that lists what the self-hosted environment must replace, including any environment other than production.
Take a full database backup
Before anything else changes, the team takes a full backup of the production database. Strapi Cloud's own backups cover only the production environment's database, so this backup must be made and stored by the team, and it should be checked for completeness before proceeding. The output is a restorable database dump stored outside the Cloud project, with its creation time and checksum recorded.
Export assets and secondary environment content
Uploaded assets are not part of Strapi Cloud's backups, so the team exports them separately, along with any content held in secondary environments. The team should confirm with Strapi which export options are available for the project before relying on any method, since moving data out of Cloud depends on those options. The output is a complete asset set and a content record for each secondary environment, each checked against the asset inventory from the first step.
Stand up the self-hosted environment
The engineering team provisions the self-hosted Strapi environment on a Node.js version that Strapi 5 supports, which means an Active or Maintenance LTS release, and on a supported SQL database such as PostgreSQL, MySQL, MariaDB or SQLite. Strapi 5 does not run on MongoDB or other NoSQL databases, so the database choice must match the version requirements in the installation docs. The output is a running instance that starts cleanly with the same Strapi version and the restored database, and the team records which Node.js and database versions it used.
Verify schema and content
The team restores the database and assets into the self-hosted environment, then compares the content types, components, roles and entry counts against the Cloud inventory. It also checks that the admin panel and the REST or GraphQL endpoints return the expected responses for key content. Any gaps are fixed before cutover. The output is a signed-off verification record listing each check and its result, which the owner keeps with the migration file.
Cut over DNS and retire the Cloud project
Once verification passes, the team lowers the DNS record time-to-live in advance if its DNS provider allows it, switches the record to the self-hosted endpoint, and monitors API traffic and error rates. The Cloud project stays available as a fallback until the team is satisfied. Downgrades are not supported after migration, so the team should not treat the Cloud project as a rollback path once data has changed on the self-hosted side. The output is live traffic on the self-hosted instance and a recorded decision about when the Cloud project will be closed.
Confirm export options before committing
Before the project is committed to either direction, the team confirms with Strapi what export options exist for its data, assets and secondary environments, and whether any of them change at the project's plan level. If the move is going the other way, from self-hosted to Cloud, the same check applies to importing existing content. The output is a written answer from Strapi that the team keeps in the migration file.
Questions buyers ask before choosing Strapi Cloud or self-hosting
What drives the cost of Strapi Cloud compared with self-hosting Strapi?
On Strapi Cloud, the main recurring cost is the per-project monthly plan: Starter is listed at 35 US dollars, Pro at 90 dollars and Business at 450 dollars per project per month, according to Strapi's Cloud pricing page. Costs rise with API request volume, asset storage and bandwidth, and extra API requests are billed at 1.50 dollars per 25,000 requests. Self-hosting shifts the spend to your cloud or data center accounts, the people who build and run the stack, and any Growth or Enterprise license. Ask for a quote that lists hosting, database, backup, staging environments, support and the internal hours each option needs, and confirm current prices on the vendor pages before you compare.
How long does a migration to or from Strapi Cloud take?
The duration depends on the number of content types, the volume of entries and assets, custom plugins, front-end integrations and how many environments you run. Strapi's documentation covers the v4 to v5 path with an upgrade tool, codemods, data migration scripts and a breaking changes list, and it says to back up the database first because downgrading is not supported. Moving between hosting models also means moving the database and assets, and the hosting region is fixed at project creation. Agree a timeline in writing against a scoped inventory of your schema, plugins and integrations, and confirm the exact steps with Strapi for your version.
Can a small team run self-hosted Strapi without outside help?
A team with working Node.js and database skills can run self-hosted Strapi, but the work recurs and it is not only installation. Strapi 5 runs only on Active or Maintenance LTS Node.js versions and supports PostgreSQL, MySQL, MariaDB and SQLite, so you must plan Node.js upgrades, database patching, backups, monitoring and security updates. Strapi has shipped Strapi 5 minor releases roughly weekly, so someone must review and test each one. If the team lacks capacity for that routine, a retainer or a fixed-scope implementation partner can cover it. Confirm the internal skills and on-call coverage you need before you decide.
What does a Growth or Enterprise license add for SSO and audit logs?
In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise, while audit logs and review workflows are Enterprise features. Growth is listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user, and content history and releases start at that tier. Strapi SSO covers administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory. It does not cover end-user authentication, which the Users and Permissions plugin handles. Confirm with Strapi which features your version and plan include before you buy.
Is an external SQL database supported on Strapi Cloud?
Strapi Cloud provides a pre-configured PostgreSQL database, and you can configure an external SQL database. Strapi warns that an external database may cause unexpected behavior or performance issues, and it states that it cannot provide security or support for one. That means the responsibility for tuning, patching, access control and recovery moves to your team or partner. Backups on Cloud cover only the production environment's database, not uploaded assets or secondary environments, so an external database needs its own backup plan. Ask Strapi to confirm the current position for your plan before you design around it.
What does the internal team need to own on either model?
On Strapi Cloud, your team still owns the content model, roles, custom code, front-end integration, content governance and the data it stores. On self-hosted Strapi, it also owns the Node.js runtime, the database, hosting, backups, restores, TLS, monitoring and upgrades. Backup scope matters: Strapi Cloud backs up Pro projects weekly and Business projects daily with 28-day retention, and Starter has no backups. Assets and secondary environments need separate handling. Write down who performs each task, how often, and how restores are tested before you commit to either model.
Which backups does Strapi Cloud take, and what do they leave out?
Strapi Cloud backs up Pro projects weekly and Business projects daily, with 28-day retention. Starter projects have no backups. The backups include only the production environment's database. They do not include uploaded assets or secondary environments, so you need a separate plan for media and any staging content. Confirm the restore procedure and recovery point objective with Strapi in writing, and compare them with what your own compliance or continuity requirements demand.
How DeployOpen scopes and supports self-hosted Strapi
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Strapi, that means working through the hosting, database, backup and upgrade decisions that separate a managed Strapi Cloud project from a self-hosted one, before any work starts.
How we scope
- Written scope covers which Strapi environments, databases, regions and backup targets you need to own yourself.
- Scope records the Strapi edition and any Growth or Enterprise features you plan to rely on, such as SSO or audit logs.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Hosting stack is built inside your infrastructure, including Node.js runtime, PostgreSQL or another supported SQL database, and asset storage.
- Admin SSO is configured against your identity provider, with end-user authentication handled separately through the Users and Permissions plugin.
- Backup jobs cover the database and uploaded assets, and are tested with a documented restore before handover.
How we hand over
- Documentation covers hosting topology, backup and restore runbooks, and the Strapi upgrade procedure for your chosen version line.
- Handover includes configuration records, access model and the evidence your compliance team needs for its own assessments.
- DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover tracking of Strapi minor releases and planned upgrades, including the Node.js version requirements for each release.
- Ask for the support scope, response expectations and upgrade responsibilities to be written into the quote before signing.
