Env setup for production and local development

[SorinGFS]

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…

[DMehaffy]

@SorinGFS

letting the admin endpoint be publicly accessible would attract a huge volume of spam (scanners, bots, etc.)

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 )

@SorinGFS

Moreover, I consider that the access to the Strapi administration panel is poorly protected.

Do you have some examples?

@SorinGFS

This is also the main reason why I split access and restrict ip based in the Nginx configuration, as follows:

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.

[DMehaffy]

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

[pm74]

@DMehaffy

• You must be using the NODE_ENV=development (the default env)
• You must be using the strapi develop command (or yarn develop / npm run develop)
• You cannot use a server.js file with the start syntax
• You cannot use the CTB in any other environment

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?

[SorinGFS]

@DMehaffy

Do you have some examples?

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.

@DMehaffy

serve it say inside of an intranet

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

[DMehaffy]

@pm74

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?

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.

[DMehaffy]

@SorinGFS

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.

Certainly is a valid point

@SorinGFS

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

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)

Boundary by HashiCorp

[SorinGFS]

@DMehaffy

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

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

[DMehaffy]

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

[SorinGFS]

@DMehaffy

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!
… 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');
strapi().start();

• and created ecosystem.config.js for pm2 with this content:

module.exports = {
  apps: [
    {
      name: 'index',
      script: 'npm',
      args: 'start',
    },
  ],
};

[pm74]

@SorinGFS

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

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?

[SorinGFS]

@pm74

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.

[DMehaffy]

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

GitHub - derrickmehaffy/strapi-digitalocean-deploy: Deploying Strapi on...

GitHub - derrickmehaffy/strapi-vultr-deploy: Deploying Strapi on Vultr with...

GitHub - derrickmehaffy/strapi-linode-deploy

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.

[DMehaffy]

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).

https://docs.ansible.com/ansible/latest/collections/community/general/hashi_vault_lookup.html

[SorinGFS]

@DMehaffy

Hashicorp, such a great company

I will definitely study boundary when I have time.

…
Derrick, can you better answer this question?

@pm74

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?

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

[pm74]

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.

[DMehaffy]

@pm74

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?

Could you? Yes
Should you? No

@pm74

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.

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.

[SorinGFS]

@pm74

The other question I have is the “npm run build” required when you update in your production env?

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.

[DMehaffy]

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 ) 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.

[SorinGFS]

@DMehaffy

Font-Awesome, because it’s massive.

Material Icons may be a good choice.