How to release from dev to stage/prd?

Hi, I’m new to strapi, but I really like it… except deployment. There are a lot of tutorials in documentation, but none of it truly describes deployment. All of them describes how to install strapi on different hosting providers. So my question is: how to deploy form dev (or staging) to production?
I’ll try to guess, based on what I’ve found out, but please help me define full deployment/release process:

  • After installing and developing locally I push all the code to repo (github)
  • Then I use some CI/CD to build from repo and deploy to server (whatever server it is)
    • Here is the first problem: which files I need to deploy, and which are not required on production server
  • Then npm install --production
  • …and app is ready to run (lets assume production env variables are already configured - .env file or host vars)
  • Now I can run the app and open it in the browser, database is updated with newest schema, but:
    • How to configure admin user?
    • How to transfer users from dev/stage to prd?
    • How to transfer all the data (content) from dev/stage to prd? << this is very important for me in first release and every next deployment
  • I know there is configuration:dump and strapi configuration:restore, but what it exacly do? Documentation about configuration ( is only about host and db, and I know that configuration:dump has nothing to do with this
  • What else should I do during deployment to keep my envs “in sync”?

You can deploy all the files from git. Except for .cache, build, node_modules folders.

I would recommend to use yarn. Since it’s much faster.

On the first run you create the admin user. Or, you can take a look at my custom plugin which creates the user for you. You can provide the admin credentials through ENV variables.

For example, .env:


To allow admin creation in production, you should also add another env variable:

You can manually export/import your DB. But do you really need to export them? I don’t think that you have more than 3 users on local env.

Well, the same procedure, export/import DB. You can write some custom script that connects to your local DB, gets the data, then connects to external DB and imports it. So every time before deploying you should update the database.

It exports the core_store table in a json file. It contains the configurations for the Admin UI.
For example, when you configure the view in admin, the config is stored in db:

Also, when you are renaming the labels for some fields:

You should manually update the envs in production before deployment. You can’t sync them automatically from local to production.

Thanks for the answer. Some of your comments need clarification.

It’s clear that .cache and node_modules shouldn’t be in repo and shouldn’t be deployed. But the build folder is product of build process (i.e. on github workflow), so why do you state that it shouldn’t be deployed?

If it’s available on the destination host. npm is much safer to use, because its always with the node.
But I get your point.

Plugin to create admin user… sorry but it doesn’t sound safe :slight_smile:
I think I’ll try strapi admin:reset-user-password command.

Yes, you’r right, I"ll skip user migration.

That was my initial idea, but I think I don’t need to export/import all the tables. The question is - records from which tables should I move, assuming I don’t want users, admin and configuration (I’ll use strapi configuration:x for this)? What is the minimal set of data I need to transfer, to keep the local content?

Because files from the build folder will contain your local URL, for example, http://localhost:1337, as it was built on the localhost with development env. If you will put your local build on the production server then you will notice that it tries to request localhost

This is why I added the build folder to gitignore in my projects. I build the frontend during deployment by using production envs with “NODE_ENV=production yarn build

You asked how to create an admin user, so the question lead me to the idea that you don’t want to create it from the login page :slight_smile: But yes, I recommend using the plugin only on local env for faster development.