How to deploy changes to production without downtime (generic hosting)?

Question

What is the recommended way to deploy changes (for example change in some Content Type model) from development to production without downtime?

I’m using this setup.

I have development instance with development postgres database. On production I have 3 strapi instances (serving both api & admin, using the same production postgres database) and those instances are behind loadbalancer.

Lets say that I have Content Type named: Article (both on development and deployed on production). Lets assume that I want to change that content type for example I want to add some fields and remove some fields in Article content type.

How to deploy changes to production without downtime?

I’ve done some tests and when I for example update Strapi Production Instance #1 to pull new code for updated models, strapi will update database of course. And from that time Strapi Production Instance #2 and #3 have problems serving Admin panel for example (javascript errors because database was changes but JS model files are not updated). After I updated code on instance #2 and #3 everything works as expected.

But doing something like this on “working product” will be visible as downtime.

How to properly handle this situation? Thanks for help!

Answer 1

I decided to post this as an answer since it felt too long for a comment.

I am considering similar setup and because of strapi updating the database on stratup I think there is no way to do it without a downtime (or accepting #2 and #3 showing errors until they get updated).

List of other (not-so-great) ideas for consideration:

• introduce an old-fashioned "down for maintenance" page on the frontend that uses this strapi backend and also in strapi admin panel as well
• take out #2 and #3 out of balancer during deployment, deploy to #1, DB gets updated, deploy to #2 and #3, then bring back #2 and #3 into balancer. This depends highly on the balancer. Would the effect be immediate for all end users to not hit #2 and #? Or would they still be hitting #2 nad #3 because of some TTL?
• improve strapi implementation (or create some kind of plugin/middleware) so that the API can work correctly with outdated models - if you keep DB changes backwards compatible this should work
• improve strapi implementation to not update the DB on stratup. Ideally admin models and DB schema should be edited separately. Admin panel would have to be able to work with DB that has "additional" fields. So e.g. first add new fields to DB, then deploy admin panel. When removing fields we first remove fields from admin models, then deploy to prod (DB is not updated), when all environments are updated - then update the DB (remove fields).

Answer 2

Could PM2 solve this problem? Strapi mentiones this in their documentation

PM2 Runtime allows you to keep your Strapi project alive and to reload it without downtime.

Strapi Docs v4