When teams need Strapi releases for scheduled publishing
Teams need Strapi Releases when a campaign, product launch or regulated update must go live as one coordinated set. A launch might touch a landing page, product entries, a shared component and translated versions of each, and those changes need to appear at the same moment in every locale. Strapi Releases is the feature built for grouping those entries into a single batch and scheduling it. Strapi's self-hosted pricing page lists releases as starting at the Growth plan. Confirm the exact scheduling behavior, including how dates and timezones are interpreted, in the Strapi documentation for the version you run before you commit a launch date to it.
Start by inventorying the full set before anyone builds the release. List every content type, entry, locale variant, media file and shared component the change touches. Then decide what the release is allowed to contain. Anything left outside the batch will publish on its own schedule or by hand, which can leave a page live in one language while another still shows old copy. Assign an owner to each entry who confirms the content is final before the release date. If your locales are not yet modeled, settle the localization design first so that each language variant is included in the batch deliberately.
Plan for what happens after the release runs. Confirm in the documentation whether entries in a release can still be edited after it publishes, whether a queued release can be rescheduled or cancelled, and how a release behaves if someone edits one of its entries during the waiting period. Treat these answers as acceptance tests. For example, in a non-production instance, create an illustrative release with two entries in two locales, schedule it a few minutes ahead, and check the API output in each locale at the scheduled time. Repeat the check using the timezone your editors work in, so the team sees the same time the system uses.
Plan choice follows from who runs the process. Because releases start at the Growth plan on self-hosted installs, a team on the free Community edition will need to upgrade before it can use them. If the same organization also needs a required approval stage before publishing or audit logs, those are Enterprise features on the same pricing page, so the plan decision should cover the whole set of controls. Ask Strapi to confirm in writing which plan and which administrator roles can create, edit and publish releases. Also confirm whether SSO is an add-on on your chosen plan, since Strapi SSO governs administrator login only.
Which self-hosted plan fits release scheduling
This table compares the three self-hosted Strapi plans on the features that shape scheduled publishing. Read the Community column first, because it has no releases, so a team that needs coordinated batches must budget for Growth at minimum. Enterprise adds review workflows and audit logs, and its pricing is quoted separately, so confirm the cost before choosing it.
| Capability | Community | Growth | Enterprise |
|---|---|---|---|
| Releases for scheduled batches | Not available, so batches cannot be grouped and scheduled in Strapi | Included, and the lowest plan that offers releases | Included, with the same release capability as Growth |
| Content history for restoring earlier versions | Not available | Included, starting at this plan | Included, with longer retention than Growth |
| Review workflows before publishing | Not available | Not available | Included, needed if a required approval stage must precede publishing |
| Audit logs of admin actions | Not available | Not available | Included, useful for tracing who scheduled or changed a release |
| SSO for administrator login | Not listed as included, confirm with Strapi | Available as an add-on | Included |
| Users and price | Free, with unlimited users | 45 US dollars per month with 3 users, plus 15 dollars per extra user (Strapi self-hosted pricing page) | Custom pricing, quoted separately |
| Choose this plan when | Editors publish items one at a time and no coordinated batch is needed | Teams need scheduled batches and history but not review gates or audit logs | Teams also need approval stages, audit trails or SSO included in the price |
How a release batches content across types and locales
A release in Strapi is a named container that collects entries from several content types and locales so they can be published as one unit. Its purpose is coordination. Changes that must go live together are handled as a single object instead of as a series of separate publish actions. Editors add entries to the release, review what it contains, and publish it. Before you adopt this pattern, decide which changes in your organization truly need to land at the same moment, because that decision determines what each release should contain.
Consider this illustrative example. A spring campaign includes a product page content type with entries in English, French and German, a promotional banner entry, and a navigation entry that links to the campaign. If these publish at different times, shoppers may see a French product page with an old price beside an English banner that advertises a new one. Placing all of these entries in one release lets the team publish them together. Map your own content types to this pattern and list every entry, locale variant and shared component that must change as a set. That list becomes the release's checklist.
Several behaviors determine whether this approach works for you, and you should confirm each one in the Strapi documentation for your version before you design around it. Check how releases handle draft and published versions of an entry, including what publishing does to the version currently live. Confirm whether adding a document adds all of its locales or whether each locale must be added separately. Find out what happens when one entry in the batch fails validation: whether the whole release is blocked or whether valid entries publish. Also confirm whether an entry can sit in more than one release and what happens if someone edits an entry after it has been added. Test each answer with a deliberately invalid entry in a staging instance.
Batching also concentrates risk. A large release is harder for a reviewer to check and harder to reverse if something is wrong, so the recovery path matters as much as the publish step. Plan for content history and database backups to cover rollback, and confirm which of these your plan includes. Decide who may create releases, who may add entries to them, and who may publish them, then verify that the admin panel roles you intend to use can perform each step on your plan. Keep batches small enough that one reviewer can check every entry in them before publishing.
Setting up a first scheduled release
This sequence takes a team from confirming plan and version eligibility to a tested, scheduled batch of content across types and locales. The output is a release that has been verified on staging, with roles set so the right people can build and change it before it publishes.
Confirm the plan and Strapi version
Before anything else, confirm that your self-hosted instance is on a plan that includes releases. Strapi's self-hosted pricing lists releases as starting at the Growth plan, so a Community instance cannot use this feature. Confirm you are running Strapi 5, because v4 reached end of life on April 30, 2026, and v4 projects should be migrated first. Check the GitHub releases page for the 5.x version you plan to run, and record the exact version in your change ticket. This step is done when the plan and version are written down and match what the admin panel reports in its settings.
Enable releases in the admin panel
Open the admin panel of a staging instance and locate the Releases feature, which is part of the content manager navigation in Strapi 5. Follow the enablement steps in the documentation for your exact 5.x version, because menu names and location can change between minor releases. An administrator performs this step. It is complete when Releases appears in the admin navigation and opens to an empty list without errors. Repeat the same check on production later, using the same version, so both environments behave alike.
Create the release and name the batch
Create a new release and give it a name that identifies the batch and its purpose, for example a quarterly product announcement (illustrative). Add a short description that states who owns the batch and which campaign or launch it supports, because the name alone will not explain the release to a colleague weeks later. Editors or content leads usually perform this step, once the roles described later are in place. It is complete when the release appears in the list with its name, description and an empty entry count, ready for content to be added.
Add entries across types and locales
Add the entries that belong to the batch, drawing from several content types as the launch requires. If a content type is localized, add each locale variant of the same document, so that the batch publishes the English, French and other language versions together rather than in separate steps. Localization must already be enabled for those types (see the internationalization page in this group). The check here is a list review: for every document in the batch, confirm each required locale is present, and confirm that no entry is in the batch by accident.
Set the publish date and timezone
Set the scheduled publish date and time, and select the timezone deliberately rather than accepting a default you have not verified. Convert the intended launch moment into a reference timezone your editors use, then compare that time with what the admin panel displays for the release. Confirm how the timezone is stored and displayed in your version by testing with a throwaway release on staging, since the display and the stored value must agree. The step is complete when the displayed scheduled time matches the intended local time in the chosen timezone.
Assign roles for creating and editing releases
Use Strapi's roles and permissions to decide who can create releases, who can add or change entries inside them, and who can trigger or manage publication. Keep these separate where your process needs it, and confirm the exact permission names in the documentation for your version. If you use review workflows on Enterprise, make sure the release roles fit the approval stages, so that no one can bypass a required review. Test the roles with a non-administrator account on staging. The step is complete when each test account can do exactly what its role allows and nothing more.
Dry-run the release on staging
Run the complete release on a staging instance that holds a copy of the relevant content, using the same version and plan as production. Confirm that every entry publishes at the scheduled time, that each locale variant appears in the API responses, and that the content matches what the batch list showed. Check what the documentation says can still be edited after a release publishes, because that determines your review window. If you transfer content to staging, follow the data transfer guidance in this group first. The dry run is complete when the staging results match the batch list, and you have recorded any differences to fix before production.
Security and operational controls around scheduled publishing
Scheduled publishing is only as safe as the people allowed to build and approve a release. These controls cover who can change a batch, whether a second person must review it, how administrators sign in, and where end-user access is decided. Check each one against your plan before the first release goes live.
Admin roles that control releases
In Strapi, creating, editing and publishing releases is governed by admin roles and permissions in the admin panel. Confirm which roles can create a release, add or remove entries, change scheduled dates and trigger publishing, and whether one role can do all four. Test the permission matrix with a non-owner account before go-live, because a single editor role that combines these actions removes any separation between drafting and publishing. Record the role model in your runbook so changes to it are reviewed like any other access change.
Unreviewed batches on Growth
A release on the Growth plan moves from scheduled to published without a review stage in between. If one editor assembles a batch of entries across content types and locales, nobody else checks the combined result before the scheduled time. The exposure grows with batch size, since one wrong date, timezone setting or unapproved entry can publish alongside everything else. Decide whether the team accepts this for the content involved, and document a manual check step if it does.
Review workflows before scheduled publishing
Review workflows are an Enterprise feature in Strapi's self-hosted plans, which makes them the control to add when scheduled publishing carries regulated content. Configure the review stages, the roles allowed to move content between them, and a required approval stage before publishing. Confirm how the workflow interacts with releases in the version you deploy, and verify that combined behavior in a test instance before relying on it.
Admin login through SSO
Strapi SSO signs administrators into the admin panel through an identity provider such as Microsoft Azure Active Directory. It supports auto-registration with a default role and an option to lock out local login. On the self-hosted plans, SSO is an add-on for Growth and included in Enterprise, so confirm the add-on cost in your quote if you are on Growth. Decide which role new accounts receive by default, and test the lock-out path so no administrator is stranded if the identity provider fails.
End-user access to published content
Visitors and applications reading published content are governed separately by the Users and Permissions plugin, and admin SSO does not change those rules. Admin roles also do not decide what an end user can read. Confirm which content types and fields are public, which require authentication, and how tokens are issued and rotated for front-end builds that read scheduled content. Test anonymous and authenticated requests after each release.
Audit trail for release changes
Audit logs are an Enterprise feature in Strapi's self-hosted plans. Confirm they are enabled before the first scheduled release so admin actions on releases can be reviewed later. Check exactly which actions are recorded, how long logs are kept on your plan, how they are exported, and whether they must be forwarded to a SIEM. Without this record, reconstructing who changed a batch and when depends on memory and manual notes.
What cannot change after a release publishes
Before you schedule a release, you need to know what is locked once its content is live. The supplied facts do not describe immutability rules specific to Strapi Releases, so you should not assume that a published release can be edited, partially reverted or cancelled. Treat that behavior as an open question to close with the vendor documentation for your exact Strapi 5 version and with a staging test, before any editor depends on it in production.
Run the test with a release that bundles at least one entry from each content type and locale it will touch. After it publishes, check whether an editor can change one entry without touching the others, whether a single item can be removed from the release's published state, and whether the release can be cancelled once its scheduled time has passed. Record the exact admin panel steps, the roles that can perform them, and any warning the interface shows. Those results become the operating rules your editors follow, so write them down rather than relying on memory of the demo.
Next, check how a published release interacts with content history. Content History on the Growth plan keeps 14 days of retention, so a change made by a release on day one may not have a history entry available by the time someone needs to roll it back. Ask whether restoring an earlier version of a document is possible for content that a release touched, and whether that restore is recorded as a new change. If the answer is no, the practical recovery path becomes a database backup, which means your backup schedule must be timed around your release calendar, not run on a generic nightly cycle.
Database backups are the other half of the recovery plan, and they need their own verification. Confirm that a restore from a backup taken just before a release brings back the pre-release state of every affected document and locale, including draft and published versions as Strapi stores them. Also confirm how you would restore only part of the content without overwriting work saved after the release published. Test the restore on a copy of your database, not the live system, and time the procedure so the team knows how long a rollback would take in practice.
Finally, decide who owns the rollback decision before anything goes live. Name the role that can authorize a rollback, the person who runs the backup restore, and the editors who must stop changes during the window. Document what happens to content edited between the publish time and the rollback, because that work may be lost if you restore from a backup. Put this decision in your release runbook and rehearse it once in staging. A rollback plan you have not tested is a risk you are accepting without knowing its size.
Limits to confirm before you rely on releases
Strapi ships Strapi 5 minor releases roughly weekly, so the release behavior you tested last month may not match the version you run today. Each card below is a limit to test in your own environment before a scheduled batch depends on it.
Release capabilities for your minor version
Release features change between Strapi 5 minor versions, and minor releases have shipped roughly weekly, for example v5.57.0 on October 7, 2026. Confirm in the Strapi release notes for your exact installed version which release actions exist, including create, edit, publish and schedule. Then run one test release on a staging copy of that version and record what it does, so the result reflects your version rather than a page written for another one.
Timezone handling in the admin panel
A scheduled release is only as accurate as the timezone it was entered in. Create a test release with a publish time set near a daylight saving change, then check the time shown to the editor, the time stored and the time the content goes live in the API response. Confirm whether the admin panel uses the editor's browser timezone or a server setting, and record the result for each locale or team that schedules content.
Maximum entries per release
A release groups entries across content types and locales, and the number it can hold determines how you split a large campaign into batches. Ask Strapi for the documented limit for your installed version, then test the largest batch you expect with realistic entry counts and relations. Measure how long the publish step takes and whether the admin panel stays responsive, since that result sets the size of batches your editors can safely schedule.
Behavior with custom APIs on the Document Service API
Strapi 5 uses the Document Service API, and custom controllers, services and routes built on it may read draft and published versions differently from the default REST endpoints. Test each custom endpoint against a release that publishes, updates and unpublishes entries, and confirm that the response shows the expected version at each step. Check custom lifecycle logic too, since it may run on a publish event that a release triggers in a batch.
Support on your self-hosted environment
This page covers self-hosting, so the release feature has to work on your own infrastructure, database and Node.js runtime, not only on a vendor-managed hosting plan. Confirm that your chosen plan includes releases, check that your database and Node.js version are supported for the installed Strapi version, and run a scheduled publish across a restart of the application. Record the result before you put a production release calendar on top of it.
Questions buyers ask about Strapi releases
How much does a Strapi Releases setup cost on the self-hosted plans?
Releases start at the Growth plan, which Strapi lists at 45 US dollars per month including 3 users, plus 15 dollars per extra user, according to its self-hosted pricing page. Enterprise is custom priced, so request that quote from Strapi directly. The license is the recurring part and grows with the number of editors. The implementation is a separate cost. DeployOpen prices it from a written scope, and the main drivers are the number of content types, locales, approval rules and the validation work needed to make batches safe. Ask any quote to separate the license, the one-time build, and any recurring support or upgrade work. Confirm current prices on the pricing page before you budget, because listed prices can change.
What makes a Strapi scheduled publishing project take longer?
Scope drives effort more than the feature itself. The largest drivers are the number of content types included in a batch, the number of locales each entry must be valid in, and the approval rules that must be satisfied before a batch can go live. Validation work is often underestimated. Every entry in a batch needs required fields and relations checked so that a batch cannot publish incomplete or broken content. Custom publishing logic, front-end rebuilds triggered after publishing, and the number of editorial teams each add design and test time. A useful scope lists the content types, locales, roles and downstream systems involved, so the effort can be estimated from facts rather than assumptions.
Can our internal team set up Strapi Releases without a partner?
Yes, for a simple batch. One or two content types, a single locale, no approval step and an editor who knows the admin panel is a reasonable first project for an internal team. It gets harder once review workflows, multiple locales, custom publishing logic or downstream rebuilds are involved, because a mistake can publish to production. Review workflows are an Enterprise feature, so check which features your plan includes before you design around them. Test every batch on a staging instance first. Teams that want an outside review of the design, validation rules and permission model can ask DeployOpen for a fixed-scope engagement.
What does DeployOpen need from our team before a Strapi release project starts?
DeployOpen needs three things from your team. First, a staging instance that mirrors production's content model, plugins and Strapi version, so batches can be tested before they are scheduled. Second, named editorial owners who approve batch content and sign off on publishing dates. Third, a written decision on who may publish a release and who may change a batch after it is scheduled. Your team should also confirm the time zone policy for schedules and the hosting environment in your own infrastructure. Without these inputs, the validation and permission design cannot be checked against how your content team actually works.
How long does a first Strapi Releases setup take?
The duration depends on scope, and no standard timeline applies to every organization. The main factors are the number of content types, the number of locales, the number of approval paths, how many environments need to be set up, and how many validation rules must be written and tested. A first setup also includes a dry run on staging, which adds time but reduces the risk of a failed production publish. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask for the timeline in that written scope and check which assumptions it depends on, such as content readiness and reviewer availability.
What cannot change after a Strapi release has been published?
Confirm the exact limits for your Strapi version in the official documentation before you design the workflow. These limits decide whether a mistake can be fixed by editing content or only by publishing a new change. Plan around them in any case. Keep batches small, validate each batch on staging, and treat the contents of a published batch as final until you have confirmed what can still be edited. Content history can help restore an earlier version, but its availability depends on your plan, and it does not replace a database backup. Document the rules you confirm so editors know what they can and cannot correct after a release goes live.
Does a Strapi release schedule follow the time zone of each editor?
Confirm this with the Strapi documentation for your version before you promise a publish time to anyone. The practical question is which time zone the schedule uses, whether the time is stored in one reference zone and shown locally, and how daylight saving changes affect it. Agree a single reference time zone for each batch, document it in the editorial guide, and state it in the batch title or description. Then test a schedule that crosses a daylight saving change on staging, and confirm the publish time that appears in the admin panel and in your API responses. Record the results so the team can repeat the check after upgrades.
What should we test before scheduling a Strapi release in production?
Test on a staging instance with data that resembles production. Check that every entry in the batch has its required fields and relations filled in, and that each locale is complete for the content types you publish. Confirm that the batch publishes in the order you expect and that dependent content is not visible before its parent. Check the API responses your front end consumes, because Strapi 5 changed the response format compared with v4. Verify that only the approved roles can create, approve and publish a batch, and run a dry schedule across a daylight saving change. Record the results and the person who approved them.
How DeployOpen scopes and delivers Strapi release workflows
DeployOpen plans Strapi release workflows as part of a wider Strapi implementation, starting with the content types, locales and publishing rules your editors use. Each engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as a retainer.
How we scope
- The written scope names which content types, locales and release batches the Strapi releases will cover.
- Scope records the plan tier required, such as Growth for releases or Enterprise for review workflows, and why.
- Time zone rules, schedule ownership and post-publish constraints are documented before any build begins.
How we build
- Release types, scheduled dates and timezone handling are configured and tested against your content model.
- Editor roles and permissions are set so only authorized people add content or change schedules.
- Test cases cover overlapping releases, locale variants and drafts that change after a release is scheduled.
How we hand over
- A runbook explains how editors create, schedule and review releases, and what to do when one fails.
- Documentation lists the Strapi plan features your releases depend on, so licensing is confirmed before go-live.
- Handover includes a walkthrough with editors and administrators, recorded against the agreed scope.
How we support
- Ongoing support covers Strapi minor releases, which have shipped roughly weekly, with changes tested before rollout.
- Retainers can include upgrades to supported Node.js and database versions, planned with your release calendar.
- Ask for a support plan that names who handles failed scheduled publishes and how they respond.
