Auto Reload feature required after running in production using ecosystem.config.js

System Information
  • Strapi Version: 3.5.3
  • Operating System: ubuntu 20.04
  • Database: mysql
  • Node Version: 14.16
  • NPM Version: 6.14.11
  • Yarn Version:

I have setup the strapi on AWS EC2 following this document AWS Deployment - Strapi Developer Documentation. Am also using pm2 and ecosystem.config.js to start the strapi it is running in production mode but i can’t add anything as it says autoReload feature is required.

content of ecosystem.config.js file

module.exports = {
apps: [
name: 'name,
script: ‘npm’,
args: ‘start’,
autorestart: true,
env: {
NODE_ENV: ‘production’

Have you built the Admin UI with production env?

NODE_ENV=production npm run build


NODE_ENV=production yarn build

1 Like

This also applies to plugins, you can’t add to remove them while in production from the Admin due to the requirement of running Strapi with the develop command to enable the auto-reload feature.

1 Like

Thank you for the information. I got the same from other links that i was reading I understand that in production restarting node will lead to downtime. Now as I make all the changes to the dev env and then migrate the data to production do I still need to restart the node app on production as I have made changes to the code and database and also is there any standard way you guys recommend to migrate data. When I added new content it added new tables with the same in DB now can i migrate just those tables or something else.

Thank you for your support :slight_smile:

Nothing currently, this is something we are planning to look at in Q3 with the database layer refactoring: Database layer (v4) - Roadmap | Product Roadmap

The best suggestion I can make, is all your local (development) data should be atomic test data or a snapshot backup of your production. Content should be created locally and pushed into production, it should only be used for testing.

Migration of content between environment is a very complex topic that will almost certainly never have a “one answer fits all”.