strapi-tool-dockerize: adding Docker to a Strapi project in one command

What the tool actually generates

The purpose is narrow: add Docker support to a Strapi project. The feature list in the project notes has three entries. It adds Docker support, it auto detects whether the project uses yarn or npm, and it builds a Docker Compose file.

That middle entry is the reason the tool exists rather than a couple of templates in a documentation page. A Strapi project is a Node application with a database connection, and the parts that differ between projects are the package manager, the database, the project type and which environments you want covered. The tool asks for those and writes the rest. The output is a set of generated files in the project, plus the environment configuration that points the application at the containerised database.

The project status is described as under development but stable in terms of state, and the maintainer is actively looking for contributors and other maintainers. The stated purpose of the package within the Strapi community is to give plugin maintainers and developers fast answers about containerising a project.

Running it, and the keyword that is required

The tool is distributed on npm under the scoped name, and the normal invocation is short:

npx @strapi-community/dockerize

It can also be called with the settings supplied directly on the command line:

npx @strapi-community/dockerize new --dbclient=mysql --dbhost=localhost --dbport=1234 --dbname=strapi --dbusername=strapi --dbpassword=strapi --projecttype=js --packagemanager=yarn --usecompose=false --env=both

The documentation draws attention to one detail with a note of its own: the new keyword is required for the arguments to take effect. That is worth knowing, because a long command line full of flags that appears to be ignored is a confusing failure, and the tool ships two command names, strapi-dockerize and strapi-strapi-tool-dockerize, for use in scripts and in package scripts respectively.

The example flags and the documented flags disagree

Here is the sharpest edge in the tool, and it is a documentation problem rather than a design one. The list of arguments in the project notes uses one set of names, with the database type given as dbtype, the user as dbuser, the project type as type and the compose switch as useCompose. The example invocation immediately above uses a different set: dbclient, dbusername, projecttype and usecompose.

One of the two is going to be ignored, and the documentation does not say which. The safe procedure is to use the documented names, and to check the result: if the compose file comes out pointing at Postgres on the default port when you asked for MySQL, you have hit the mismatch. It is a small thing, but it is the sort of small thing that costs an afternoon the first time and is invisible in the file listing afterwards, since the tool writes a plausible file either way.

The documented defaults are worth having in mind for the same reason. The database type defaults to postgres, the host to localhost, the port to 5432, and the database name, user and password all default to strapi. The project type defaults to js, the package manager to yarn, the compose switch to false, and the environment to development.

Which databases the compose file can carry

The Compose support covers three databases, and the versions are pinned in the notes rather than left to the newest tag. Postgres is version 16, MySQL is version 8, and MariaDB is the latest release. The type argument accepts postgres, mysql or mariadb, and the port default of 5432 is the Postgres one, so switching to MySQL or MariaDB means changing the port as well, to 3306.

The environment argument is the other dimension that shapes the output. It takes development, production or both, and defaults to development, so a single run of the tool leaves you with the development configuration and no production files. Choosing both is the way to get a pair of environment configurations written at once, which is the common case for a project that is about to be deployed somewhere. The password default of strapi is a development convenience and nothing else, so the generated configuration is worth reading before it goes anywhere near a server.

The reset command deletes a configuration folder

There is a second command, and it is destructive in a way that is easy to skim past. The reset invocation is:

npx @strapi-community/dockerize reset

The note attached to it says plainly that RESET will delete the config/env folder with all of its content. That is the folder the tool itself generated and wrote into, so resetting throws away the generated environment configuration and puts the project back to the state before the tool ran. It does not touch the rest of the project, which is reassuring, but it does mean that any manual edits you made to the generated files, such as a password you changed or a host you pointed at your own database, are gone as well, and the command asks no questions before doing it.

Strapi v5 is the target, and v4 needs an older release

The version line matters more here than in most tools, because the note is explicit: this version targets Strapi v5, and for Strapi v4 support you should use an earlier release. Strapi 5 changed enough about the project layout and the server configuration that files generated for one major version are not simply wrong for the other, so running the current tool on a v4 project is likely to produce a compose file that does not behave.

The published release history makes the timeline clear. The versions v1.16.0, v1.16.1 and v1.16.2 were published in July and August 2023, and the last push to the repository was on 2026-07-09. The manifest carries a placeholder version of 0.0.0-development because the release is handled by semantic release tooling, which means the number you install from npm is decided by the commit messages rather than by hand.

A template engine, a CLI framework and one maintainer

The dependency list shows what the tool is made of, and it is a familiar set of small libraries. A template engine, liquidjs, does the file generation, and the CLI is built on meow with a help renderer and an interactive prompt library for the questions. A spinner library keeps the user informed, chalk handles the coloured output, fs-extra does the file copying, execa runs the child processes, and replace-in-file edits existing files in place, which is how the tool rewrites the database connection settings in your Strapi configuration.

There are a few extras worth naming. A library that builds a GitHub issue URL is included, which suggests a path for reporting problems without leaving the terminal, and a package that opens a URL is there for the same reason, and one that handles errors and unhandled rejections so a failed run prints something useful. On the tooling side, the project uses semantic release on the main branch, a conventional changelog commit helper, eslint and prettier, and the source is split into a cli directory, a core directory, a utils directory and a templates directory, with an index file at the root. The package is MIT licensed, published under the Strapi Community organisation, and the project notes credit a single author with a short list of contributors behind it.

Editorial conclusion

strapi-tool-dockerize suits a developer who has a working Strapi project on their laptop and wants a containerised version of it for a colleague or a CI runner, since the whole job is generating the files rather than teaching you Docker. It is the wrong choice if you need to understand exactly what lands in your repository, because the tool writes a config directory and a compose file for you, and it is the wrong choice if you are on Strapi v4, since this version targets v5 and the earlier release is the one for v4. Before you run it, read the flag list rather than copying the example command, because the names in the example differ from the documented ones, and remember that the reset command deletes the config/env folder and everything in it. The licence is MIT, the last push was on 2026-07-09, and the published releases are from 2023.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. strapi-community/strapi-tool-dockerize on GitHub