Any organization running Strapi in production, whether a digital agency operating across a portfolio of clients, an enterprise tech team supporting internal business units, or a product team running a single critical project, eventually faces the same underlying choice. The CMS itself isn't the question, your team has already chosen Strapi for good reasons. The question is what to do with the operational layer underneath it: the servers, databases, environments, backups, monitoring and deployments that make every project actually work in production.

That layer doesn't go away. You can keep it sitting with your team, absorbed into the engineering capacity you'd rather be spending on product and client work, or you can hand it off to Strapi Cloud instead.

Self-hosted vs Strapi Cloud

Setting up a new project

On self-hosted Strapi, every new project starts with infrastructure work before any content modeling or development begins. Your team provisions a server, installs and configures PostgreSQL, sets up SSL certificates, defines staging and production environments, configures backup schedules, and documents the setup so it can be maintained by someone other than the person who built it.

On Strapi Cloud, setup is a guided flow that connects your Strapi project to managed infrastructure in minutes.

Log in to the Cloud dashboard with GitHub, GitLab, Google, or a one-time password, then click Create project from the projects page.

In the Project’s creation page you choose a plan (Free, Essential, Pro, or Scale) and a billing cycle.

You select the GitHub or GitLab account and the repository you want to deploy.

You set the general information for the project: a display name and the Git branch you want to deploy. You select the hosting region for your servers (US East, Europe West, or Asia Southeast) and create the project. Optional advanced settings let you specify a base directory, environment variables, and a Node version.

What happens next is the part worth noticing. Strapi Cloud provisions the database, hosting, SSL, and CDN, and runs the first deployment from your repository. None of that is your team's work. No PostgreSQL install. No SSL certificate to issue and renew. No CDN to configure. No deploy pipeline to wire up. The pieces that would have taken days self-hosted are in place by the time the project finishes deploying. From that point your team works in their normal Strapi codebase. Pushing to the connected branch can trigger automatic deployments if "Deploy on push" is enabled, or deployments can be triggered manually from the dashboard or the Cloud CLI.

Environments and deployments

Self-hosting means your team builds and maintains every environment from scratch. Staging, QA, and production all have to be provisioned, kept in parity, and managed independently. Promoting changes between them is your team's process to design, document, and run.

On Strapi Cloud, every project includes a default Production environment.

On the Pro plan, you can add up to 99 additional environments, billed per environment. The Scale plan includes one additional environment in the base price. Each environment is connected to its own Git branch, with its own variables and its own domain.

Each environment has a Configuration tab that lets you change the connected branch, the Node version, and the base directory for monorepo setups.

Data transfer between environments is in beta on Pro and Scale plans. You can import the entire content database and assets from one environment into another secondary environment, which is useful for testing changes against production data or staging content before going live.

Deployments themselves can be triggered manually from the dashboard, manually from the Cloud CLI, or automatically on every push to the connected branch. Ongoing deployments can be canceled from either the dashboard or the CLI if needed.

Updates and maintenance

Self-hosting means tracking Strapi releases, planning upgrade windows, testing each version in staging before promoting to production, and coordinating with stakeholders when there's any risk of downtime. On top of Strapi itself, your team is also responsible for patching the underlying OS, runtime, and database. Critical security patches drop on someone else's schedule, and the work has to be absorbed somewhere.

On Strapi Cloud, the platform layer is maintained for you.

When a new Strapi version is available, your team upgrades it in your own codebase, pushes to the connected branch, and Cloud redeploys.

Staging environments on Pro and Scale plans let you test the upgrade before promoting it to Production.

The work of staying current on infrastructure stops being your team's job. The work of choosing when to adopt new Strapi capabilities stays where it belongs, with you.

Performance and scaling

When a self-hosted project faces a traffic spike, your team has to have predicted it. Capacity has to be provisioned ahead of campaigns, monitoring has to alert the right people, and someone has to respond if the prediction was wrong. Capacity that goes unused between spikes is still paid for.

On Strapi Cloud, performance is managed through plan-based limits and a global asset CDN, with caching available for app responses.

Each plan has defined limits on API requests per month, asset storage, and asset bandwidth. Free starts at 2,500 API requests and 10GB storage. Essential moves to 50,000 requests and 50GB. Pro is 1,000,000 requests and 250GB. Scale is 10,000,000 requests and 1,000GB.

If your project exceeds API requests, asset bandwidth, or asset storage on a paid plan, overages are billed at fixed published rates, which means scaling doesn't break the platform, it shows up on the next invoice.

Free plan projects scale to zero after a period of inactivity, with cold starts up to a minute when traffic returns. Paid plans disable scale-to-zero, so response times stay consistent.

Incident response

On self-hosted infrastructure, incident response is end to end your team's responsibility. Diagnosis, fix, stakeholder communication, and post-mortem all sit with the people you'd rather have on builds.

On Strapi Cloud, incidents at the infrastructure layer are handled by Strapi.

Platform issues, outages, and underlying system problems are detected and addressed by Strapi's team, not yours.

When an issue does need your attention, runtime logs and deployment history are visible from the dashboard, with deployment logs available live during builds.

Support is plan-based. Free has no included support. Essential and Pro include Basic support. Scale includes Standard support. The escalation path scales with the plan rather than being a single fixed level for everyone.

Collaboration and access

On Strapi Cloud, sharing a project with a teammate or external collaborator follows a consistent flow.

The project owner clicks Share in the project dashboard and invites someone by email. The invited person becomes a maintainer once they accept.

Maintainers can access the project dashboard, manage deployments, and work in the project. They cannot share the project to others, delete the project, or access billing.

This is project-level access, not Strapi CMS user access. The Strapi admin panel still has its own admin users with the role-based access control that comes with Strapi CMS itself.

Project ownership can be transferred to an existing maintainer when needed, for example when handing over a client project or rotating internal ownership.

Cost predictability

Self-hosted infrastructure costs are variable and distributed across your engineering capacity. The hosting bill is one number, but the true cost of running a project includes the engineering time spent on the infrastructure layer, which is rarely captured cleanly. That makes per-project economics hard to model when you're pricing a retainer or planning a budget.

Strapi Cloud makes the per-project number visible.

Pricing is structured per project on one of four plans, billed monthly or yearly.

Each plan defines its limits up front: database entries, asset storage, asset bandwidth, API requests, emails. Backups are weekly on Pro and daily on Scale, with 28-day retention. Custom domains are included on every paid plan.

What used to be hard to model becomes easy to compare against the value the project generates.

When usage exceeds a limit, the project doesn't stop. Overages on API requests, asset bandwidth, and asset storage are billed monthly at published rates rather than blocking the project.

Overages aren't allowed on Free, which suspends instead, but on paid plans they keep things running while making the cost of growth explicit.

Add-ons like additional environments are billed on the same cycle as the plan.

Each project's usage is tracked in the Dashboard, which makes it straightforward to absorb pricing into a retainer, pass it through to a client, or allocate it to an internal business unit.

Portability

Self-hosting means you already own everything, so portability isn't a concern. Strapi Cloud is built on the same open-source Strapi, and your data and code remain yours. Your project lives in your own GitHub or GitLab repository. Database backups can be downloaded as .sql files from the Backups tab on Pro and Scale plans. If you ever decide to move back to self-hosting or to another setup, you take your code, your data, and your content with you. There's no proprietary lock-in, which matters for any organization that's been burned before by platforms designed to make leaving painful.

What this means for your team

Most teams don't decide to run their own infrastructure. They drift into it because that's how they started, and the operational layer accumulates one project, one client, one upgrade at a time. Self-hosting becomes the default, not the choice.

Strapi Cloud is the alternative. Setup is a guided flow that takes minutes instead of days. Maintenance, backups, SSL, and the rest of the operational layer are handled for you. Pricing is predictable per project, so you know what each one costs before the first deployment runs. Environments come ready to use, with staging and production set up as part of the standard project structure. Inviting a teammate or a client stakeholder is a few clicks instead of an access management project. Deployments run automatically on every push to your connected branch, so shipping changes is part of the same workflow your team already uses.

If your team is still self-hosting today, it's worth asking whether that's still the right call, or just the one you've never had a reason to revisit. Well, now you have some reasons.