Dockerfile Generator

Dockerfile generator - an image skeleton for PHP-FPM, Node.js and Python

The Dockerfile generator assembles the file that builds a container image for four common stacks: PHP-FPM (Laravel, for example), PHP CLI with the built-in server, Node.js and Python. You choose the runtime version and the port, and the tool orders the instructions so that layer caching keeps working, adds a non-root user and wires up a ready HEALTHCHECK.

What this tool does

The generator does not inspect your project - it assembles a reviewed template from the fields you select. For PHP-FPM it installs extensions through docker-php-ext-install together with the required header libraries and drops the build toolchain in the same layer, so the image stays small. With the Laravel option checked it adds route and view caching plus ownership of storage. For Node.js it sets NODE_ENV=production, and for Python it creates an appuser account, because the -slim image ships no application user.

Instructions in the generated file

How to use the generator

1. Pick the base image. PHP-FPM suits applications behind an HTTP server, PHP CLI fits scripts and quick tests, Node.js and Python cover your own services.
2. Set the runtime version - the list only contains releases that still have current official images.
3. Enter the port your application listens on. The field is hidden for PHP-FPM, because FPM always exposes 9000.
4. Click Generate Dockerfile and save the result as a Dockerfile in the root of your repository.
5. Add a .dockerignore, or COPY . . will pull the dependency directory and your local configuration into the image. The gitignore generator gives you a pattern list to start from.

docker build -t my-application:1.0 .
docker run --rm -d -p 8080:8080 --env-file .env --name my-application my-application:1.0
docker ps --filter name=my-application

Layer caching and instruction order

Docker stores the result of every instruction as a layer and reuses it until something that layer depends on changes. That is why the manifests (composer.json, package*.json, requirements.txt) are copied before the code: a fix in a controller no longer invalidates the package install, and the build finishes in seconds instead of minutes. Chaining matters too - build packages added in one RUN and removed in the next still occupy space, because the layer that installed them is already written.

Non-root user and secrets

By default a container process runs as root, which means any flaw in the application hands an attacker full rights over the image file system. The generated file switches to www-data, node or appuser only after the installs are done, because before that point it would lack permission to write to system directories. Directory permissions are quick to work out with the chmod calculator.

Laravel adds one more detail: php artisan config:cache executed during the build freezes the environment variables from the build stage rather than the production ones. The generator bakes in only the route and view caches and leaves configuration caching to container start-up.

Dockerfile, docker-compose and Kubernetes

A Dockerfile describes a single image. Running several services together - application, database, Redis, HTTP server - is the job of docker-compose.yml, whose syntax you can check with the YAML validator. A cluster rollout is described by the Kubernetes Deployment manifest generator, and when traffic is served through Apache the .htaccess file generator helps.

Frequently asked questions