Env setup for production and local development

[pm74]

@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

ok, so if I use a different database for each env, then how does the database gets updated between env? You have a command similar to “php artisan migrate” or just doing the npm build will take care of updating the database?

[DMehaffy]

Currently there isn’t any tooling for this other than the core_store table in the database (Content-Manager views for both list and edit) in which case you can use the CLI options to dump/restore these:

• Dump: https://strapi.io/documentation/developer-docs/latest/cli/CLI.html#strapi-configuration-dump
• Restore: https://strapi.io/documentation/developer-docs/latest/cli/CLI.html#strapi-configuration-restore

For your data, these migrations need to be done manually, also for schema changes we don’t handle this yet (See: Deleting/Updating content-type doesn't drop/migrate the database · Issue #1114 · strapi/strapi · GitHub)

---

To the above points, we have a database refresh coming in Q3: Database layer (v4) - Roadmap | Product Roadmap

Among the changes we want to handle:

• Automatically clean up deleted tables (models)
• Automatically clean up deleted columns (fields)
• Automatically rename columns when changes are made in Strapi
• Provide some basic tooling to migrate Users, Roles, Permissions, and Data between environments

What isn’t planned for this refresh but we want to do:

• Migration from other CMSes (headless, decoupled, or monolithic)
• Advanced migrations for Strapi updates
• Automated migrations for Strapi updates

---

A strong point I would like to make, if you plan on having a large database (or just want to maintain your sanity) I suggest you avoid MongoDB for non-hobby projects.

• PostgreSQL for single node speed
• MariaDB Galera Clusters for HA/LB high load applications
• MySQL if you are more familiar with their clustering solution.

[SorinGFS]

@DMehaffy

avoid MongoDB for non-hobby projects

what are the problems with mongoDB?

[DMehaffy]

@SorinGFS

what are the problems with mongoDB?

Mainly performance but there are some issues with data management and migrations. But to put it bluntly it’s a nightmare to properly maintain a production MongoDB database (bias opinion I suppose, but I prefer to give it to you all straight).

To put it another way: Strapi is a strict schema, relational, headless CMS

MongoDB is neither strict schema, nor relational (and we don’t follow their best practices regarding child documents over multiple collections, effectively we treat it as a relational DB anyway)

SQL (PG/MDB/MSQL/SQLite) are all strict schema and relational databases. Strapi was practically designed around how SQL functions even if it wasn’t the first database we suggested. There is a reason SQLite became the quickstart option

---

Source on MongoDB being a nightmare, I provide support, I look at any production MongoDB server and it gives me a headache. It will wake me up in the middle of the night with terrors

[SorinGFS]

Sad! I like sqlite, but I wouldn’t relly on it for large projects. And from the other choices mongoDB is my favorite…

[SorinGFS]

@pm74

So I would have to dump the production database load it in development, make the changes, and then update it back in production hoping they didn’t add more data while I was coding in development.

You have to put them in sync somehow, on your own, Strapi does not handle this after your deployment. That’s why I said different dev / prod databases cannot be used, for me is like a nightmare to mentain such a setup, and is a non sense too.

In simpler words, development and production must be on the same server, with the delimitation of access paths.

Of course, maybe Derrick has a different solution…

[pm74]

Yea I deleted my post because I realized the command is called “strapi configuration:dump”
Technically this means that only the configuration is dumped, and the user cannot make changes to the configuration. If it’s only dumping the configuration then you wouldn’t need the data content from production in dev. Then these restore and dump command seems to be a viable option.

But I’m using Strapi just for the website content and to provide a way for the owner to be able to quickly make changes if they wanted to. This data is not that critical so using the same database in both env is not a big issue from my perspective.

[SorinGFS]

@pm74

But I’m using Strapi just for the website content and to provide a way for the owner to be able to quickly make changes if they wanted to. This data is not that critical so using the same database in both env is not a big issue from my perspective.

If you use different access paths and if you add extra security to the /admin path you can use same database for both dev/prod without fear on any project…

[pm74]

@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

Hey @DMehaffy I will have to do it in our private network. I really need to be able to run in development mode via PM2 and keep it on all the time in development mode within our private development network.

Do you know what is the configuration to accomplish that?
I tried the configuration below but it just didn’t work. It would show as if it was in development mode but when connected you cannot edit anything.

@pm74

module.exports = {
       apps: [{
           name: 'strapiProd',
           cwd: '/mnt/data/strapi/Prod',
           script: 'npm',
           args: 'start',
           env: {
             NODE_ENV: 'production',
             DATABASE_HOST: 'localhost', // database endpoint
             DATABASE_PORT: '3306',
             DATABASE_NAME: '', // DB name
             DATABASE_USERNAME: 'strapi', // your username for psql
             DATABASE_PASSWORD: '', // your password for psql
           },
         },{
           name: 'strapiDev',
           cwd: '/mnt/data/strapi/dev',
           script: 'npm',
           args: 'start',
           env: {
             NODE_ENV: 'development',
             DATABASE_HOST: 'localhost', // database endpoint
             DATABASE_PORT: '3306',
             DATABASE_NAME: '', // DB name
             DATABASE_USERNAME: '', // your username for psql
             DATABASE_PASSWORD: '', // your password for psql
           },
         },
       ],
     };

[pm74]

@pm74

Do you know what is the configuration to accomplish that?
I tried the configuration below but it just didn’t work. It would show as if it was in development mode but when connected you cannot edit anything.

Ok, I got it working now. For the development section, all I needed was to change the “args”
script: ‘npm’,
args: ‘run develop’,

[DMehaffy]

The short answer to both of you @pm74 and @SorinGFS is your development and production environments should be atomic, the data on those should not matter in the slightest.

Usually you would pull down some snapshot (or cleaned snapshot) of the production database, make a few changes, and build a .sql migration script if required. I was just updating a personal project from v3.0.x to v3.4.x and did the exact same thing:

CAPIv2-Strapi/scripts/Migration at development · canonn-science/CAPIv2-Strapi