What a Strapi implementation involves
Strapi is a headless CMS written in Node.js and TypeScript. It stores content in a SQL database, generates REST endpoints for each content type, adds GraphQL through an official plugin, and gives editors a React admin panel. Websites and apps read content through the API, so the public site is a separate application.
A customized implementation covers the content model and API contract, business logic in controllers, services and middlewares, plugins, integrations, preview and publishing, migration from the previous CMS, and hosting the application with its database and media storage.
The repository is MIT licensed, except code in ee/ directories, which falls under a separate Strapi Enterprise license. Admin SSO needs the Enterprise plan or the SSO add-on with Growth, and audit logs and review workflows need Enterprise. Match requirements to plan features during discovery, since that affects license and budget.
Components of a self-hosted deployment
Node.js application
Serves the admin panel and API. Strapi supports only Active LTS and Maintenance LTS releases of Node.js. Build in CI and run in production mode.
Database
PostgreSQL, MySQL, MariaDB or SQLite. Strapi 5 lists PostgreSQL 14 and MySQL 8.0 as minimums and does not support MongoDB. SQLite suits local development.
Media storage
Files go to local disk by default. Strapi maintains Amazon S3 and Cloudinary providers. Use object storage for containers or more than one instance.
CDN and caching
Cache public read endpoints in a CDN or the front end's data layer, and purge or rebuild from webhooks on publish.
Model content types, components and dynamic zones
The content model is code. The Content-type Builder writes schema files and works only in development, so schema changes reach production through Git and a deployment.
| Building block | Use it for | Watch for |
|---|---|---|
| Collection types | Articles, products, people, locations. | API consumers depend on names, so keep them stable. |
| Single types | Homepage, global settings, navigation. | Split by owner before one type collects unrelated fields. |
| Components | Reusable groups such as SEO metadata or call-to-action blocks. | Keep nesting shallow so queries stay manageable. |
| Dynamic zones | Pages editors assemble from components. | Front ends must render every allowed component, so keep the set small. |
| Relations | Authors, categories, related content. | Strapi 5 uses documentId, and related data returns only when requested with populate. |
Where custom code goes
Custom routes add endpoints. Policies run before the handler as a read-only check that can block access, so keep authorization rules there where they are easy to review.
Keep controllers thin and put reusable business logic in services that controllers and scheduled tasks share. Extend core controllers when a standard endpoint needs custom behavior.
Strapi 5 runs content operations through the Document Service API. Strapi recommends its middlewares over Query Engine lifecycle hooks, which are meant for cases needing direct database access.
Confirm every Marketplace plugin supports Strapi 5, and keep project-specific logic in local plugins. Webhooks notify front ends, search indexers and caches; make handlers idempotent.
Integrations to plan
Front ends and preview
Front ends fetch content through REST or GraphQL. Preview opens the front end from the admin panel; Live Preview beside the edit view is on Growth and Enterprise.
Admin identity
SSO for editors and administrators requires Enterprise or the Growth SSO add-on. Without it, protect the admin panel at the network layer.
End users and tokens
Users and Permissions authenticates app users with JWTs and Public and Authenticated roles. Server-side clients use read-only, full or custom API tokens.
Search and commerce
Webhooks or plugins feed search services. Product data usually stays in a commerce or PIM system, with Strapi holding editorial content that references it.
Migration, testing and launch
Strapi 4 reached end of life on April 30, 2026. The upgrade tool (npx @strapi/upgrade major) updates dependencies and runs codemods, and database migrations run when Strapi 5 first starts. Back up first, since there is no automated downgrade.
Most of the work is in code and consumers. The Document Service API replaces the deprecated Entity Service API, REST responses drop the attributes wrapper, and GraphQL no longer exposes numeric IDs. A Strapi-Response-Format: v4 header lets front ends change gradually. Plugins need Strapi 5 versions.
From WordPress, Contentful or a custom database, scripts read the export and write through the Document Service API. Map rich text to blocks or Markdown, relink images and add redirects in the front end.
Test custom endpoints as each role and token type, load-test reads through the CDN, make alt text required where needed, and train editors on staging before switching front ends one at a time.
Harden and run self-hosted Strapi
| Area | Practice | Check |
|---|---|---|
| Secrets | App keys, JWT secrets and token salts per environment from a secret store. | No .env file is in Git. |
| Roles and tokens | Grant Public and Authenticated roles only what each front end needs. | Anonymous requests for drafts, users or writes are refused. |
| API limits | Set GraphQL depthLimit and maxLimit, which are unlimited by default, and cap REST page sizes. | Deeply nested or oversized queries are rejected. |
| Security updates | Only Strapi 5 receives fixes. Detailed advisories follow fixes by two to eight weeks depending on severity. | Strapi and npm updates are reviewed on a schedule. |
| Backups | Database, media and repository together. strapi transfer skips admin users and API tokens, so it does not replace a backup. | A restore into a clean environment passes API smoke tests. |
| Scaling | Several instances need a shared database, external media storage and scheduled tasks that run once. | Restarting one instance does not interrupt traffic. |
Strapi operating ownership
A headless setup splits ownership between the CMS, the front ends that read from it and the people who write the content.
Platform team
- Runs Strapi, the database and media storage.
- Applies Node.js, Strapi and dependency updates.
Developers
- Own content types, endpoints and plugins.
- Agree schema changes with front-end teams.
Content owners
- Own locales and publishing rules.
- Review editor accounts on a schedule.
Security
- Reviews roles, API tokens and admin accounts.
- Tests custom endpoints for authorization gaps.
Strapi implementation questions
Should we use Strapi Cloud or self-host?
Strapi Cloud is Strapi's managed hosting. Self-hosting suits teams that need content in their own infrastructure, region or private network, and it means running the database, storage, backups and upgrades yourselves.
Can we stay on Strapi 4 for now?
Strapi 4 no longer receives security fixes. Plan the move to Strapi 5, and until then limit network exposure of the admin panel and API.
How do we change the schema without breaking front ends?
Treat the API as a contract: add fields before removing old ones, release front ends that tolerate new components first, and generate TypeScript types from the schema.
Scope and handover
DeployOpen designs the content model and API contract with your front-end teams, builds custom endpoints, middlewares and plugins, integrates identity, search and webhooks, upgrades Strapi 4 projects or migrates content, and deploys Strapi in your infrastructure. Security testing covers endpoint authorization, token scopes and GraphQL limits, and DeployOpen documents access reviews, patching and backup tests as SOC 2 or ISO 27001 readiness evidence for your auditor.
Handover includes the repository with schemas and plugins, the API change process, the role and token inventory, environment setup, restore test results and editor guides.
