Backend - Strapi 5

Setup & configuration

Strapi runs in a node.js (version 20.18) docker container. The Strapi source code is pulled from the respective docker repository, build using Vite, and the ./app/build directory is mapped into the docker container as a volume.

Strapi's Admin panel needs to be build during install and with every new version deployed. The docker-compose.yml has been set up in a way that if the folder ~/docker/strapi/app/build - that is where the final Admin Panel code is stored - does not exist, it initiates the build process. If this folder exists, Strapi is simply started without initiating the build process. For deploying new releases it's useful to execute the steps manually (see below).

We need to constrain the Strapi Admin Panel build process in memory as it is running into a memory limit fast. The constraint must be carefully balanced though - if not enough memory is given to the build, then the build also fails. For now, we are working with NODE_OPTIONS="--max_old_space_size=1600".

WARNING

Still the build process of the Strapi's Admin Panel is rather resource consuming and should be executed under close supervision

Environment Variables

Strapi uses various requirement variables located in ~/docker/strapi/app/.env:

• HOST:

  The IP address at which this server is exposed, set to 0.0.0.0 for all available IP's

• PORT:

  The port under which the Strapi Admin Panel can be reached

• PUBLIC_URL:

  The public URL of the Strapi Server.

  DANGER

  This must be properly set, otherwise Strapi backend is not accessible.

• STRAPI_FRONTEND_URL:

  The URL under which the Frontend can be reached

• STRAPI_ENV:

  Staging, Development or Production, used internally to re-direct certain processes e.g. emails

• APP_KEYS, API_TOKEN_SALT, ADMIN_JWT_SECRET, TRANSFER_TOKEN_SALT, JWT_SECRET:

  Standard Strapi variables used for secure internal and external communication

• METABASE_SECRET_KEY:

  The key which is required to authenticate against Metabase to load the reporting iFrame

• DATABASE_CLIENT, DATABASE_HOST, DATABASE_PORT, DATABASE_NAME, DATABASE_PASSWORD, DATABASE_SSL, DATABASE_FILENAME_:

  Standard Strapi variables to establish the connection to the selected database

• MAILGUN_API_KEY;

  The API Key for the Mailgun account used to send emails

• MAILGUN_DOMAIN:

  The domain used to send out the Mailgun emails

• ALLOWED_ORIGINS:

  The origins which are allowed access against the CORS policies

Deployment

To deploy a new version/release to the production environment we need to do the following steps (all commands assuming that we navigated to ~/docker/strapi first):

• cd app && git pull to pull the latest version of the repository

• for changes to backend functions, e.g., cron jobs or lifecycle functions without changes to the data model or the Admin Panel, we only need to restart the Strapi docker container:

      docker restart strapi

  The website (frontend) will always be available during the restart process (max 1min), the API calls to the backend will fail

• For changes to the Admin Panel, data model etc., we have to rebuild the Admin Panel and restart the docker container. To be on the safe side we should also update the package install, in case new packages were added:

      docker exec -it strapi yarn install 
      docker exec -it strapi yarn build
      docker restart strapi

  TIP

  In this case deleting the app/builddirectory is not required

  The website will be available and fully functional during the Admin Panel build process. The downtime is limited to the time the docker container restarts as above. It is recommended watching the memory usage (including swap) during the Admin Panel build process in a second terminal window using top. Should the server run out of memory during the build process it needs to be restarted/rebooted from the exabytes admin console.

  The Admin Panel itself will not be available from moment the ./app/build directory is deleted.

Backup & Restore

1. The complete Strapi setup is backed up using the inherent backup tool of Strapi. The backup process is managed through ~/scripts/strapi/backup_strapi.sh. The script is executed by a cron job daily at 3.15am and the backup file is stored under ~/cloud/google/Backups/strapi_backup.tar.gz.enc

   INFO

   Whilst this Backup file contains most of the data stored in Strapi it is not complete (e.g., users/roles tables are missing), that is why the database is backed up in addition. On the other hand the Strapi backup file is the only way to restore the media files in the /uploads folder correctly, i.e. in a way that the links to the files work. Both backups are needed.

2. Whilst this copies most of Strapi's configuration and data the complete mysql database is also backed up including the strapi_db. For further details see