Running Strapi on AWS Elastic Beanstalk

Strapi is a NodeJS based open source CMS. At present it is in active development and in alpha and probably not something you would run in production. Having been experimenting with this, whilst there are articles documenting docker setups, Elastic beanstalk was something I was really familiar with and would usually beable to setup a CI pipeline to Elastic beanstalk in a few mins so I went down this rabbit hole...

The biggest problem with Strapi is the built package size which stems from individual node_modules dependencies for strapi root, strapi admin and each of the individual plugins. While mostly the same packages, each of them needed to download the dependencies and store them in separate locations resulting in a built package too large for Elasticbeanstalk to deploy.

So the trick i had to do was to build the strapi package

npm run setup --plugins

then delete the node dependencies.

With Codebuild, you'd have a buildspec.yml like

version: 0.1

phases:
 install:
   commands:
 pre_build:
   commands:
     - echo Installing source NPM dependencies...
     - npm install --silent
 build:
   commands:
     - echo Build started on `date`
     - npm run --silent setup --plugins
 post_build:
   commands:
     - echo Cleaning up node_modules
     - rm -rf admin/node_modules
     - rm -rf plugins/*/node_modules
     - rm -rf node_modules
     - echo Build completed on `date`
artifacts:
 files:
   - ‘**/*’

However, with all the node dependencies gone from the package, after deploying to the instances you need to re-download them.

You can do so by running

npm run postinstall

Or simply add a prestart script step to package.json,

 "prestart": "npm run postinstall"

Adding prestart script meant you wont need to call additional scripts separately, just call

npm start

and it would automatically run the prestart script.

!: NOTE: This increases the deployment time significantly as it needs to reinstall all the node dependencies for the plugins, admin etc. However, to soften the blow, I went with a rolling additional host deployment where the existing instance is only blowed away when the newly provisioned host is ready after it finishes the prestart and start.