Popular posts

That's some good questions. So size of images would depend on the strapi and endpoints etc. But I would say it's not the most optimized image I bet it can be further improved. I think node + strapi for development is 1-2gb due npm modules etc and the base image. While production is a bit smaller as it uses alpine.

Git based vs docker Under the hood heroku is using heroku ish which again uses docker. So by using git that procfile tells it how to run its container. I just find it easier to keep it in my own image and container as I can deploy it really to any service that has it. Gcp, As, azure, dokku, DO etc. Without changing much. As I can prebuild an image and use it everywhere. With git based i guess you need a bit of configuration for just it's deployment depending on where you are deploying it to.

Simen Daehlin Yeah, all correct with regards to heroku, that's why there is no big advantage of docker over good old git-based.

And, ideally Docker would give you that freedom you are talking about, yes. But with Strapi it is not so rosy. Strapi violates the principles of 12-factor app (the third one, to be precise) and embeds some of the environment variables in code at the build stage. At least one I am aware of (learned it the hard way) forum.strapi.io/t/deployed-strapi-admin-panel-try… Essentially that environment variable discussed in that thread gets burned into your Strapi build which makes the docker images not very reusable like you would expect. So, some suggested if you have multiple environments for a few customers, you are multiplying docker images. Combine it with the large image size and you will start questioning if Strapi is ready for container-based workflows.

I guess there is still value in docker here. Using Dockerfile and docker in general as the way of describing dependencies and installation process is somewhat universal and will work across various environments (AWS, GCP, whatever) compared to having a proc file that only Heroku would understand.