What Strapi upgrades and support involve
After go-live, a self-hosted Strapi 5 project needs a recurring routine: applying minor releases, moving the Node.js runtime when its LTS status changes, updating plugins and custom code against new Strapi releases, patching dependencies that carry security fixes, and watching the production environment. Strapi 5 minor releases have shipped roughly weekly, for example v5.56.0 on September 30, 2026 and v5.57.0 on October 7, 2026, so this is ongoing work rather than a one-off project. Each release needs to be read against your plugins and custom controllers, tested in a staging copy of the database, and then rolled out.
Four kinds of event usually start a piece of work. A project that has just left Strapi v4 (end of life on April 30, 2026) often finds its first months on v5 full of follow-up fixes. A dependency advisory may require a patched package even when Strapi itself is unchanged. A Node.js version leaving LTS support means Strapi must move to a runtime it supports, because Strapi 5 only runs on Active or Maintenance LTS versions. The fourth is a release that changes a plugin your project depends on, which can break custom code without any change on your side.
Teams often keep this in house when they can absorb the release cadence and have an engineer who owns the admin panel, the database and the on-call rota. Many hand the routine to a partner when the release load competes with product work or when no one is clearly on call for a production CMS. Confirm with your own team how many releases per quarter you can test, who receives vendor and advisory notifications, and who is paged when the content API fails at night. Those answers decide which model fits.
What the service includes
Ongoing support for a self-hosted Strapi 5 project covers the releases, runtimes, plugins, dependencies, databases and backups that a change can affect. Each work stream ends in a named record you keep, and response handling is set in the written scope.
Release tracking and minor upgrades
Strapi 5 minor releases have shipped roughly weekly, so we track the GitHub release feed, review each changelog, and apply upgrades to a staging copy first. You receive a changelog review and an upgrade record for every change promoted to production, including the version moved from and to.
Node.js runtime moves
Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so runtime moves are scheduled against Strapi's supported list rather than the newest release. We check build tooling, native modules and container base images on staging before cutover. You receive a runtime compatibility note with the tested version pair.
Plugin and custom plugin compatibility
Marketplace plugins and custom plugins can break on a minor release even when the core upgrade succeeds. We run each installed plugin and your custom controllers, services and lifecycle hooks against the target version and record any API or admin panel changes. You receive a plugin compatibility matrix with pass, fail and pending status per item.
Dependency and container image patching
npm dependencies, base images and the operating system packages under your Strapi container need regular patching, and some fixes arrive outside Strapi releases. We scan dependencies, test patched builds in staging and roll them out in a planned window. You receive a patch report listing each advisory, the package or image changed, and the test result.
Database engine version checks
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. Before each change we confirm your engine version sits inside that range and plan any engine upgrade as a separate change. You receive a database version check recorded with the upgrade record.
Backup verification before each change
Strapi's migration guidance says to back up the database first because downgrading is not supported, so every change starts with a restore test. We restore the latest backup to a separate environment, confirm content and media resolve, and record the time taken. You receive a verified backup record and a tested rollback note for the change.
Support channel and response handling
Issues found after launch arrive through a named channel, are triaged by severity, and are tracked to closure. Response targets, hours and escalation paths are not promised here and are set in the written scope before work starts. You receive a support log with each request, its triage outcome and the agreed handling status.
What drives the cost and effort of ongoing support
This table lists the factors that change how much testing, patching and coordination a Strapi project needs after launch, why each one matters, and how to keep it manageable.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom content types | Each custom schema affects API responses, permissions and migrations, so changes in Strapi releases can touch many collections at once. | Keep the content model lean, document each type's purpose and owner, and remove unused types before go-live. |
| Custom controllers, services and routes | Custom code relies on Strapi internals such as the Document Service API, so each piece must be retested on every upgrade. | Prefer core APIs over overrides, keep custom code in small modules with tests, and limit the number of custom routes. |
| Custom plugins and admin panel changes | Admin panel customizations and in-house plugins depend on internal interfaces that can shift between minor releases. | Scope admin changes tightly, pin the Strapi version each plugin supports, and keep a regression checklist for the admin panel. |
| Third-party plugins | Each community plugin has its own release cycle, maintenance status and compatibility with the current Strapi 5 minor version. | Choose actively maintained plugins, record the version in use, and remove plugins that no longer receive updates. |
| Number of environments | Production, staging and development each need the same upgrade, data and configuration checks, so effort multiplies with environment count. | Keep environments as close to production as practical, script deployments, and promote the same build through each environment. |
| Integrations with front ends and external systems | Changes to response format, authentication or webhooks can break Next.js, Nuxt, mobile apps or CRM and ERP connections even when Strapi itself works. | Define API contracts, run integration tests against staging, and agree a change notice process with each consuming team. |
| Node.js and database version drift | Strapi 5 runs only on Active or Maintenance LTS Node.js versions and supports specific PostgreSQL, MySQL, MariaDB and SQLite versions, so host runtime changes can force upgrades. | Track the supported Node.js and database matrix in the Strapi installation docs, and plan runtime changes alongside Strapi releases. |
| Edition and plan choice | Growth SSO is an add-on, while audit logs and review workflows are Enterprise features, so compliance or access needs can change the support scope and the number of configurations to test. | Confirm which features your team needs before launch, and document any add-on or plan change as part of the support scope. |
| Compliance evidence requirements | Assessors may ask for records of each upgrade, test result, access review and change approval, which adds documentation work to every release. | Use a standard change record template, keep test results with each release, and agree with your auditor which evidence is required. |
| Releases applied per cycle | Strapi 5 minor releases have shipped roughly weekly, so skipping several versions creates a larger combined change set to test. | Set a regular review cadence, apply releases in batches on a fixed schedule, and read release notes before each batch. |
How a support cycle runs
The recurring sequence keeps a Strapi 5 project on a supported version with a tested rollback path, and each step closes with a written record the client can keep.
Onboard and baseline the project
For a project the partner has not maintained before, the first phase reviews the codebase, plugins, custom code and hosting, then records the Strapi version, Node.js version, database version and hosting setup. The output is a written inventory and a list of known gaps, which the client confirms before any change is planned.
Take a recurring inventory
At the start of each cycle, the team checks the current Strapi version, installed plugins, Node.js version against the Active or Maintenance LTS list, database engine and version, and hosting environment. The output is an updated baseline that shows what has drifted since the last cycle.
Review release notes and breaking changes
The team reads the GitHub release notes for each Strapi 5 minor release in scope, then checks the breaking changes list and plugin release notes against the custom code and configuration in the project. The output is a short impact note that marks each change as no action, test focus or required code change.
Upgrade a staging copy after a database backup
The team takes a full database backup first, because Strapi does not support downgrading, then applies the upgrade to a staging copy of the production database and files. The output is a staging build that starts cleanly and a backup that has been checked for restore readiness.
Run regression tests on content, APIs and roles
The team tests content types, REST and GraphQL responses, admin roles and permissions, and the front-end calls that consume the API, comparing results with the pre-upgrade baseline. The output is a signed test record listing each failure, its fix and whether it blocks the change.
Deploy in an agreed production change window
The team deploys the tested build in a change window agreed with the client, following the backup and restore plan written for this change. The output is a change record with the times, versions and backup reference, and a restore path that stays ready until verification finishes.
Verify production and close with a report
After deployment, the team checks critical API calls, admin login, content publishing and monitoring alerts, then issues a closing report with the versions, test results, issues and open items. The output is the report and an updated baseline that starts the next cycle.
What usually goes wrong after launch
Most Strapi problems after launch come from small changes left unmanaged for months. The patterns below show where upgrades stall, and the prevention step for each one.
Minor releases skipped until upgrades stall
Strapi 5 minor releases have shipped about weekly, for example v5.56.0 on September 30, v5.57.0 on October 7 and v5.58.0 on October 14, 2026. A project that skips several of them accumulates API and dependency drift, so each upgrade becomes a project. Pin the Strapi version in package.json and the lockfile, review release notes on a fixed monthly cadence, and apply minor updates through a staging gate.
Node.js version leaves the supported set
Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so the application can keep running on a runtime that no longer receives upstream fixes. Confirm the current supported Node.js versions against the Strapi installation requirements and the Node.js release schedule. Pin the runtime in the container image or host config, and track its end-of-life date on the same calendar as Strapi releases.
Custom plugins and hooks break after core changes
Custom controllers, services and lifecycle hooks often call the Entity Service API, which Strapi 5 replaces with the Document Service API. Response format changes can also break front ends, and the Strapi-Response-Format: v4 header is a migration aid, not a permanent fix. Third-party plugins may lag core releases, so check each plugin's compatibility before upgrading and keep contract tests for your own endpoints and hooks.
Unpatched transitive dependencies after launch
Vulnerabilities often arrive in indirect npm packages that the project never imports directly, and they are flagged months after go-live. Run a dependency scan on a fixed schedule against the committed lockfile, and record who triages each finding and within what window. Apply fixes through the same staging gate as Strapi releases, so security patches do not bypass testing.
Production upgrades without a tested restore path
Strapi's migration guidance says to back up the database before upgrading, because downgrading is not supported. A backup that has never been restored does not prove a rollback exists. Rehearse a restore on a copy of production, include uploads and environment configuration in the plan, and document the rollback steps and the decision point for invoking them before any production upgrade starts.
Admin accounts and API tokens left unreviewed
Staff changes leave administrator accounts, roles and API tokens behind, and tokens may still hold broader scopes than they need. For SSO-backed admin login, review the default role assigned on auto-registration and whether local login lock-out is enabled. Review admin users and token scopes on a schedule, and revoke access in the offboarding checklist so it does not depend on memory.
Recurring costs after go-live
This table lists each recurring cost after a Strapi 5 go-live, who is paid for it, and what to request in a quote, with edition and Cloud prices shown as vendor list prices to recheck on the day of purchase.
| Cost component | What it covers | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Support or retainer fee | Upgrades to new Strapi 5 minor releases, Node.js LTS changes, plugin updates and dependency security fixes, within agreed response handling | Recurring | Named scope, response handling, number of included releases and what falls outside the retainer |
| Internal staff time | Approvals of each release, business testing of content flows and API consumers, and review of release notes | Recurring, per release cycle | A test checklist your team signs off, and a list of tasks your staff must own |
| Hosting and staging | Production and staging servers or containers, Node.js runtime and reverse proxy in infrastructure you control | Recurring | Who provisions and pays the hosting bill, and whether staging matches production |
| Database and storage operations | Upkeep of PostgreSQL, MySQL or MariaDB, minor patching windows and growth of the uploads volume | Recurring | Supported database versions, patching windows, and storage growth assumptions |
| Backup storage and restore testing | Database and upload backups taken before each upgrade, plus periodic restore drills | Recurring storage, one-time setup of restore tests | Retention period, restore test frequency and where results are recorded |
| Community edition | Free, with unlimited users, REST and GraphQL APIs and unlimited entries and API calls per the Strapi self-hosted pricing page | No license fee | Confirm that every feature you need is available in Community before you choose it |
| Growth edition | Listed at 45 US dollars per month for 3 users, plus 15 dollars per extra user. SSO is an add-on. Vendor list price. | Recurring | Current list price on the day of purchase, user count and whether SSO is priced separately |
| Enterprise edition | Custom priced. Audit logs and review workflows are Enterprise features. Vendor pricing page. | Recurring, negotiated | Written price, term length, included support and the features your compliance team needs |
| Strapi Cloud plans | Starter 35, Pro 90 and Business 450 US dollars per month per project as vendor list prices. Business includes a 99.9% uptime SLA. | Recurring | Confirm current list prices and SLA terms on the Strapi Cloud pricing page on the day of purchase |
How the work changes by starting point
A Strapi 5 project on the Community Edition has no vendor-managed admin features, so the upgrade routine depends on your own release testing and records.
- Intake: Inventory the exact Strapi version, installed plugins, Node.js version and database engine, then check each against the current installation requirements.
- Testing: Minor releases have shipped roughly weekly, so set a cadence that batches them into a defined window. Test content types, custom APIs and public endpoints on a staging copy with production-like data.
- Deployment: Take a database backup before each upgrade. Downgrading is not supported, so the backup is the rollback path.
- Evidence: Keep a dated record of versions deployed, test results and rollback notes for each window.
- Client provides: A staging environment, repository access and a named owner who approves each change.
On Growth or Enterprise, admin SSO, audit logs and review workflows are configuration that must still work after every upgrade, so each change needs a check of those controls.
- Intake: Confirm the licensed plan and whether the SSO add-on is included. Record the identity provider settings, auto-registration, default role and whether local login lock-out is enabled.
- Testing: After each upgrade, test admin sign-in through the identity provider, role mapping and that audit log entries still capture administrator actions.
- Deployment: Schedule changes to SSO or role settings apart from routine minor releases so that a fault can be traced to one change.
- Evidence: Export the identity and role configuration and keep audit log samples from before and after each change.
- Client provides: Identity provider administrator access, test accounts for each admin role and proof of the licensed plan. End-user login through the Users and Permissions plugin is tested separately.
Projects that moved from v4 often keep transitional code, so the routine starts by confirming which compatibility pieces are still needed. The move itself is covered in the sibling Strapi v4 to v5 migration topic.
- Intake: List every consumer that sends or relies on the Strapi-Response-Format: v4 header, and every custom call that still uses the Entity Service API or expects v4 response shapes. Strapi v4 reached end of life on April 30, 2026, so v4 fixes are no longer available.
- Testing: Test each front end that reads the header. Remove the header only after each consumer is confirmed on the v5 response format.
- Deployment: Remove compatibility code in its own change, not bundled with a minor release.
- Evidence: Record which endpoints depended on the header and the date each shim was removed.
- Client provides: Access to front-end repositories, a list of API consumers and the rollback record from the original migration.
On Kubernetes, the upgrade is a new container image rolled across replicas, so the routine must confirm that old and new pods can run side by side during the rollout.
- Intake: Confirm the pinned Node.js version in the image, the supported database engine and the connection pool size per replica, since several instances share one database.
- Testing: Run each upgrade in a staging cluster with the same replica count. Check that old and new pods serve requests during the rollout and that readiness probes gate traffic correctly.
- Deployment: Use a rolling strategy and confirm how data migration scripts behave when several replicas start. Plan schema changes so they run once, and confirm the behavior with the vendor docs before go-live.
- Evidence: Store image digests, manifests and rollout logs with the change record.
- Client provides: Cluster and registry access, secrets management details and an agreed maintenance window.
In an air-gapped or restricted network, the upgrade cannot pull packages from public sources, so every release, dependency and container image must enter through an approved path.
- Intake: Define the transfer path for Strapi packages, npm dependencies, Node.js installers and container images, and name who approves each transfer.
- Testing: Rebuild the dependency set inside the boundary and run the full test suite there. Confirm how plugin packages and Node.js LTS installers are mirrored before the first transfer.
- Deployment: Transfer artifacts with checksums and record each import. Because minor releases ship often, batch them so that each transfer covers a defined set of changes.
- Evidence: Keep transfer logs, approvals, checksums and a software bill of materials if your policy requires one.
- Client provides: An internal artifact repository, a documented transfer approval process and a named reviewer inside the boundary.
What your team needs to provide
Your team has to supply several inputs before a Strapi upgrade and support cycle can start. Read access to the Git repository and the deployment pipeline comes first, because every minor release is applied through code and build steps that we need to see. A staging environment that matches production in Strapi version, Node.js version, database engine and configuration is the second requirement. Without it, a weekly minor release can only be tested against a different system than the one users depend on.
Give us the list of custom plugins, lifecycle hooks and custom controllers or services, and identify which ones your team owns. Also provide the front-end and integration consumers of the API, including any scheduled jobs, webhooks and mobile clients that call it. A current database backup routine with a restore you have tested recently is required, since Strapi's migration guidance says to back up the database before any change and downgrading is not supported. Confirm the Node.js and database versions in your environment against the supported lists in the Strapi installation documentation before we start, and record any gap as a risk.
Decisions your team must make: choose the release channel you want to follow, decide how often minor releases are applied (for example, on a fixed cadence or only when a security fix is published), and set a maintenance window policy that states who approves a window and how much notice users receive. Also confirm which Strapi edition and which SSO arrangement are in force, because SSO for administrators is a paid add-on on Growth and included in Enterprise, and audit logs and review workflows are Enterprise features. These choices change what we test and what we patch.
Name an owner for approvals and business sign-off, plus an on-call contact and an escalation path that covers weekends and holidays. Support work moves faster when the person who can accept a content model change or a release risk is known in advance. Agree these names, their backups and response expectations in writing before the first cycle, and make sure they are reflected in the contract or statement of work.
Frequently asked questions
How often do Strapi 5 minor releases need to be applied?
Strapi 5 minor releases ship frequently, roughly weekly in recent months, including v5.56.0 on September 30, v5.57.0 on October 7 and v5.58.0 on October 14, 2026. Whether every release must be installed is a policy decision for your team. Confirm with Strapi which releases carry security fixes and how long each release line is patched. Most teams set a regular review cadence, such as monthly, and apply releases to staging first. Ask DeployOpen to set that cadence in the support scope.
Can our own team run Strapi upgrades in house?
Yes, if your team has the skills and time for it. Upgrades need working knowledge of Node.js, the Strapi project structure, your database, your plugins and your deployment pipeline. 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, so skills built on those will not carry over. Ask whether the same people can cover upgrades, testing and incident response, since a missed runtime change can block a release.
What makes a support retainer cost more than a one-time upgrade?
A one-time upgrade is a fixed scope with a defined start and end. A retainer pays for recurring work: release monitoring, scheduled upgrades, dependency and security patches, and incident response within an agreed scope. Costs rise with the number of environments, plugins, custom code, integrations and how often releases are applied. Your team provides access to repositories and environments, a named contact and decisions on priorities. Ask each quote to list included activities, response expectations and exclusions. DeployOpen quotes follow from the written scope.
How long does one Strapi upgrade cycle take?
No single duration applies, because the time depends on what the project contains. The main drivers are the number of installed plugins and whether each one has a release that works with your target Strapi version, the amount of custom controllers, services and lifecycle hooks, the number of environments to test through, and how much content and schema must be verified. Ask for the scope to list each plugin and custom component, so the effort is based on your actual project. Also ask how staging is refreshed from production.
What happens when a Node.js version leaves LTS?
Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so once your version leaves that set, the project should move to a supported version. Treat this as its own change: check the installed Strapi release and each plugin against the new Node.js version in staging, update the runtime in your build and hosting images, and run your test suite. Confirm the current list of supported Node.js versions in Strapi's installation documentation before you schedule the change.
Can a failed Strapi upgrade be rolled back to the previous version?
Strapi's documentation says downgrading is not supported, so a rollback means restoring the database and application code from backups taken before the upgrade. Back up the database first, keep the previous application build available, and test the restore in a separate environment before the production change. Strapi's v4 to v5 migration runs data migration scripts on first start, which makes a tested backup essential. Confirm with Strapi which steps are reversible for each release, and agree in writing how restore points and restore time are handled in your support scope.
How DeployOpen delivers Strapi support
DeployOpen plans, upgrades, documents and supports self-hosted Strapi inside your own cloud accounts, data centers or air-gapped networks. Every engagement starts from a written scope, so upgrades, handover and ongoing support are agreed before work begins.
How we scope
- We confirm the Strapi version, database, Node.js version and plugins in use before quoting.
- The written scope names the upgrade path, such as a Strapi 5 minor update or v4 to v5 move.
- Engagements are fixed-scope, and ongoing support can run as a retainer after launch.
How we build
- We check each planned minor release against your plugins and custom code in a staging copy.
- We run Node.js LTS and database version changes in a staging copy before production.
- Dependency security fixes are tested with the same staging checks before they reach production.
How we hand over
- Before any upgrade, we take a database backup, since Strapi does not support downgrading.
- Each engagement ends with written runbooks covering the upgrade steps, rollback plan and configuration.
- Your team receives the change log, test results and environment details for each release applied.
How we support
- Retainers cover routine minor release reviews, plugin updates and dependency security patching on a schedule agreed in writing.
- Because Strapi 5 ships minor releases roughly weekly, the agreed schedule sets how often we review them.
- Support scope, response expectations and any service levels are confirmed in writing before work starts.
