Env setup for production and local development

Questions and Answers
15

You will need to set the permissions in production as well as dev/staging, those are stored in the database and aren’t in source control.

16

Can you give some examples? Because this sounds like a bug but it depends on what you mean.

17

First, thank you for the details. Regarding the opt for subdomains, as you said… where possible! From my point of view this opt is not quite an option, mostly the type of the project dictates what is should be!

Yes, not easy task, but again, in my case not splitting is not an option! Imagine an eCommerce site, letting the admin endpoint be publicly accessible would attract a huge volume of spam (scanners, bots, etc.). Moreover, I consider that the access to the Strapi administration panel is poorly protected. This is also the main reason why I split access and restrict ip based in the Nginx configuration, as follows:

// nginx (inside isolated admin location)
location /admin {
    Allow 123.123.123.123;
    Deny All;
    ...
}
18

I’m logged in with the super user and cannot create content, the server things I’m in Production mode.
If I do yarn develop it works, but I cannot get it to work with my above mentioned configuration.

image
image1081×700 56.6 KB

19

Which permission are you talking about here?

20

Ah alright this isn’t RBAC then this is normal Strapi default. We forcefully disable the CTB (Content-Type builder) in Production and Staging. Even in development mode it will only be enabled under a very specific set of circumstances:

  • 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

For reasons why I’ll lead you to this FAQ entry: Troubleshooting - Strapi Developer Documentation

But will post it here also:

Strapi stores model configuration files (what defines the model schema) in files such as api/restaurant/models/restaurant.settings.json. Due to how Node.js works, in order for changes to take effect, that would require Node to restart the server. This could potentially cause downtime of your production service and likewise these changes should be tracked in some kind of source control.

Generally your “flow” of development would follow the following path:

  • Development - Develop your Strapi application locally on your host machine, then push changes into source control
  • Staging - Deploy changes from source control to a “production-like” environment for testing
  • Production - If no other changes are needed, deploy into production
  • Repeat as needed, it is recommended that you properly version and test your application as you go

At this time and in the future there is no plan to allow model creating or updating while in a production environment, and there is currently no plans to move model settings into the database. There is no known nor recommended workarounds for this.

1 Like
21

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…

2 Likes
22

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.

23

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

1 Like
24

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?

25

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.

26

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
27

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
28

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

29

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

30

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');
strapi().start();
  • and created ecosystem.config.js for pm2 with this content:
module.exports = {
  apps: [
    {
      name: 'index',
      script: 'npm',
      args: 'start',
    },
  ],
};
31

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?

32

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

33

@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
34

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

2 Likes