Env setup for production and local development

When I make changes to server.js I always rebuild the admin panel, by erasing the cache and build folders and by running npm run build -- --clean. See docs…


It would yes just as it does on most applications, security through obscurity helps with automated bots that aren’t aware of your work-around but they don’t prevent humans from digging (as someone who does as a hobby to submit CVEs or bug reports to services :wink: )

Do you have some examples?

This is certainly a good policy, I’ll say it’s a tad overkill but is very effective. Honestly you can deploy Strapi without the admin panel entirely and simply serve it say inside of an intranet so long as it can reach the backend API then there is no real risk.

(Sorry to both of you btw, there is kinda 2 convos going on here)

1 Like

Thank you very much.
If I understand correctly I cannot configure strapi to automatically run with PM2 at boot time in development mode?
When I want to use CTB I must start my dev node with strapi develop from the command line?

Last I checked the admin access token was saved in sessionStorage, and in plain text. For many ppl this is ok, but not for me, since that token is like an ever token, initially expires after a month but once is captured will work for ever.

It was just an example, I need to provide limited remote web access for some devs without intranet access.

There is a way to run it with PM2 but, and I don’t say this lightly, I strongly, like 200%, advise against this

Effectively yes, you should run locally, make your changes, push into GitHub/GitLab/Bitbucket/whatever and deploy that to staging to test your changes, and if all is good, push into production.

1 Like

Certainly is a valid point

Understand that as well, something potentially for you to research as this style of access control is becoming quite popular instead of the alternative (VPNs, Intranets, Bastions, ect)

1 Like

Without pm2 how does Strapi goes back online after a reboot?

Short answer is it doesn’t, the point of the development mode is the user controls it. PM2 is a service (or process manager) so it’s running the node application as a service. There are some alternatives like forever: forever - npm but PM2 has the widest feature range for things like built in node clustering, systemd and init startup services, user scoped services (so you aren’t running as root), ect.

PM2 => Production and staging on a server
The Strapi development is designed to be run manually by a developer locally

This is exactly how I use it! :grinning:
… as I specified here Env setup for production and local development - #5 by SorinGFS

I configured pm2 like this:

  • created index.js file inside project root folder with this content:
const strapi = require('strapi');
  • and created ecosystem.config.js for pm2 with this content:
module.exports = {
  apps: [
      name: 'index',
      script: 'npm',
      args: 'start',

It doesn’t, you have to run strapi develop.
I agree not to let it run permanently in dev mode, what I did is configure a dev sub domain in nginx, and whenever I need to run in development I just run “strapi develop” and then I can use my subdomain dev URL to get to it.

Do you have documentation on how to deploy in different environments?

What I have been doing is the following:
Make changes in the development project /strapi/dev

Then I go in the production folder: /strapi/prod or /strapi/stage
Update code, run build – --clean, and that’s it.

I’m sharing the same database for development and production so I don’t have to update the database. But if I was to use different databases, how does it get updated?

As far as I know, different dev / prod databases cannot be used.

@pm74 while these aren’t done yet, nor are they Strapi official:

And my very early WIP documentation for them: https://docs.strapi.guru

I’ve only really tested Terraform on DigitalOcean and Linode, done full testing on Vultr, and am writing out the ansible documentation for all 3. Eventually I’ll also get to GCP and AWS but wanted to get these 3 out of the way first.

They all use Terraform for the infrastructure setup and Ansible for deploying the database/application/nginx configuration/SSL cert generation.

1 Like

A lot of these are inspired by how we actually deploy stuff internally at Strapi for our own infrastructure, along with previous experience and how a single person like me can run and maintain about 30 different applications as a single DevOps person on various hobby projects.

Just because I say single devops, doesn’t mean these options don’t scale, especially with Terraform (God I love Hashicorp, such a great company). You can easily store Terraform state files in a central storage like Consul (self-deployed or their cloud) and easily maintain deployments with strict control for multiple devops personnel. Same for storing secrets in Vault (you can even use Hashicorp’s Vault system with Ansible).



I will definitely study boundary when I have time.

Derrick, can you better answer this question?

I have no deployment experience, I imagine you can’t have development on one server and production on a different host …

The other question I have is the “npm run build” required when you update in your production env?
Because this creates downtime when it builds.

Could you? Yes
Should you? No

Only when a production variable has changed (generally only the root url key in server.js or anything in the admin object of the server.js

Likewise if you update any Strapi package versions you have to rebuild. Changing models, no. Any modifications to the Admin panel, or plugin Admin extensions is yes (not controllers, services, ect).

The easiest way to know if you need to rebuild, if you think it is compiled into the react build of the admin panel, you should rebuild. Anything based on the Koa backend you don’t.

You have to run npm run build on:

  • migrations
  • manual changes in config files

Chenges through admin panel are managed by Strapi. This is what I know, but Derrick may add some extra cases.

One other point to make, we are planning an Admin Panel design refresh (sorry I can’t share more details about this yet, all I have to say is come to StrapiConf in April :stuck_out_tongue: ) but we are looking at removing/replacing the two largest contributors to the Admin size and build time:

  • Moment.js (replace it with something much much smaller)
  • Font-Awesome, because it’s massive.
1 Like

Material Icons may be a good choice.