# webdevops/Dockerfile for Configurable PHP and Web Server Images

> webdevops/Dockerfile generates PHP-FPM, Apache, and Nginx images with predefined extensions, environment-based configuration, and optional multi-service startup. It fits developers who want prepared PHP container variants, but its generated-image workflow and legacy build tooling require careful evaluation.

**webdevops/Dockerfile** — :package: Dockerfiles from WebDevOps for PHP, Apache and Nginx

- Repository: https://github.com/webdevops/Dockerfile
- Website: https://webdevops.io/projects/dockerfiles/
- Stars: 1,734 · Forks: 490
- Language: Shell
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/webdevops-dockerfile

## What webdevops/Dockerfile Adds to Official PHP Images

webdevops/Dockerfile targets developers who need PHP application containers with common server and extension choices already assembled. Its images extend the official PHP images rather than introducing a PHP runtime from scratch. The documented variants cover `php`, `php-dev`, `php-apache`, and `php-nginx`, each with Debian or Alpine forms and PHP versions from 8.1 through 8.5. Development and server variants are separate tags, so an application team can select the runtime shape it needs instead of treating every extension as mandatory.

The README says the images include almost any PHP module preinstalled and use environment variables to control configuration. It also describes images that can run services such as `php-fpm` and `nginx` together through `supervisord`. That combination is useful for small application deployments that want one container entry point, although the documentation does not describe a production architecture for separating those services.

The intended audience includes both image consumers and contributors who regenerate the repository's Dockerfiles. A consumer can choose a published `webdevops/php-*` tag. A contributor starts from files under `template` and `provisioning`, generates files under `docker`, and must not edit those generated files manually. This distinction matters because the project is both a collection of container images and a generation system for maintaining them.

## Template, Provisioning, and Docker Directory Data Flow

The repository uses a generation pipeline rather than treating each Dockerfile as the primary hand-edited source. According to the README, Jinja2 templates in `template` and configuration files in `provisioning` are processed by the build environment. The resulting files are written inside `docker`, and the README explicitly states that those files are never modified manually. Top-level entries such as `Makefile`, `conf`, `ci`, `tests`, and the documentation directory support that pipeline.

The mechanism is partly legacy. The README describes the build process as a mixture of Python Jinja2 and PHP code. The Makefile reinforces that transition by defining `provision` with `python2 bin/console generate:dockerfile` and `python2 bin/console generate:provision`, while its build and test targets also call `python2`. A prospective maintainer therefore has to account for both old Python generation paths and newer PHP-based CI generation.

CI generation takes a different route. The documented commands install Composer dependencies in `/app/ci` and execute `ci/console github:generate` from `/app`. The README says this creates a multi-stage GitLab CI configuration. Each image is then built independently, with ServerSpec and structure tests run before it is pushed to the registry. This explains why contributors should modify templates and provisioning data rather than patching a generated Dockerfile.

## Generating Dockerfiles and Preparing a First Local Build

The README does not present a conventional installation command for consumers, such as a documented `docker pull` walkthrough. It points users to the image names listed under the supported Debian PHP and Alpine PHP sections. The documented setup workflow is aimed at repository contributors. It runs the build environment, mounts the checkout at `/app`, and invokes the `provision` Make target.

From the repository root, run the command below. It should generate the Dockerfile and provisioning output before you inspect or build an image.

```bash
docker run --rm -ti -v $PWD:/app -w /app webdevops/dockerfile-build-env make provision
```

The Makefile shows that this target invokes `python2 bin/console generate:dockerfile` and `python2 bin/console generate:provision`. A contributor should review the resulting changes under `docker` and treat them as generated output. The README does not provide a complete local consumer setup after generation, so it would be speculative to add undocumented flags or configuration values here.

For the CI-oriented generation path, the README documents two separate containers. Run the first to install Composer dependencies under `ci`:

```bash
docker run --rm -ti -v $PWD:/app -w /app/ci webdevops/php:8.4-alpine composer install
```

Then generate the GitHub or GitLab-related pipeline configuration from the repository root:

```bash
docker run --rm -ti -v $PWD:/app -w /app webdevops/php:8.4-alpine ci/console github:generate
```

The README states that CI builds each image independently and runs ServerSpec and structure tests before registry publication. It does not document rollback procedures for published image tags.

## Debian and Alpine Image Selection Boundaries

Image selection is explicit rather than implied by a single universal tag. Debian examples use names such as `webdevops/php:8.4`, `webdevops/php-apache:8.4`, and `webdevops/php-nginx:8.4`. Alpine uses the corresponding names with `-alpine`, including `webdevops/php:8.4-alpine`. The same distinction appears for `php-dev`, Apache, Nginx, and their development variants.

The README says Debian images are based on `php:{VER}-fpm-buster`, while Alpine images are based on `php:{VER}-fpm-alpine`. This gives adopters a concrete first compatibility check: compare the distribution-specific tag with the base operating system required by the application. It does not provide a table explaining the exact module set for every tag, so tag names alone cannot establish extension parity.

Environment-variable configuration is another boundary. The README names this feature but does not enumerate all supported variables or provide a complete example that selects extensions, changes worker settings, or configures both PHP-FPM and Nginx. The linked external documentation would be needed for that detail. Based on the repository layout, configuration templates appear to be represented under `conf` and related provisioning paths, but the README does not document every key or its runtime effect.

Container architecture also needs a deliberate choice. A combined PHP-FPM and Nginx image can reduce the number of processes managed at runtime, but the README does not describe signal handling, readiness checks, persistent storage, or multi-container orchestration. Those concerns remain outside the documented scope.

## Legacy Build Tooling and Maintenance Boundaries

The repository is not archived, and the last push was on 2026-10-02. That fact indicates recent repository activity, but it does not erase the compatibility constraints visible in the build files. The Makefile directly depends on `python2` for provisioning, local builds, testing, and image generation. Teams without a suitable Python 2 execution path may need to use containers or resolve the legacy dependency before contributing through the documented Make targets.

Documentation is another adoption constraint. The README describes the old Read the Docs documentation as available and the newer GitBook documentation as currently being written. It also says the documentation is only partly up to date. That warning matters because environment variables, service behavior, and supported tags can change without this README providing their full reference.

The project is licensed under MIT. The repository contains a `LICENSE` file, which is the starting point for checking permitted use, modification, distribution, and notice obligations. No separate commercial-use restriction is identified in the repository description, but this review does not interpret the license text or provide legal advice.

Upgrade cost is therefore concentrated in build compatibility and image inspection. The README lists separate tags for PHP 8.1 through 8.5, but it does not describe an upgrade procedure, compatibility matrix for extensions, or policy for retired versions. Adopters must inspect the target tag rather than assume that changing the PHP number is a drop-in replacement.

## Why Official PHP Images Are a Different Choice

The official PHP Docker images are the clearest alternative because webdevops/Dockerfile explicitly builds on them. The official images provide the base PHP-FPM runtime, while webdevops/Dockerfile adds predefined variants, commonly installed modules, environment-based configuration, and support for running PHP-FPM with Nginx or Apache through `supervisord`.

Choose an official PHP image when minimizing project-specific image layers and keeping runtime construction close to the upstream base is more important than preinstalled convenience. Choose webdevops/Dockerfile when its generated variants save setup work and its service model matches the deployment. A conventional application architecture that already separates PHP-FPM, Nginx, and persistent workloads may gain little from a combined image.

There is no documented instruction in the README for importing application source, choosing a document root, mounting data, or setting a production startup command. That absence makes the project unsuitable as the sole deployment recipe for a new application without additional application-specific work. Its strongest documented use is as a prepared image family or as a generator for images whose configuration is inspected before release.

## Conclusion

Adopt webdevops/Dockerfile when a project needs its prepared PHP, Apache, and Nginx image variants and is willing to inspect generated configuration for each PHP version. Do not adopt it if your team requires a documented current installation and release process, because the README points to documentation it describes as incomplete and the Makefile still invokes `python2`. Verify first that the required image tag exists for your PHP version and distribution, then inspect the generated Dockerfile and its environment-driven service configuration before deployment.

## FAQ

### Which webdevops/Dockerfile PHP image should I choose?

Choose between `php`, `php-dev`, `php-apache`, and `php-nginx` tags, then select Debian or Alpine and a PHP version from 8.1 through 8.5. The README does not provide an exact extension-by-extension comparison.

### How do I generate the Dockerfiles in webdevops/Dockerfile?

Run the documented `webdevops/dockerfile-build-env make provision` command from the repository root. According to the README and Makefile, this uses the `template` and `provisioning` directories to generate files under `docker`.

### Can webdevops/Dockerfile run PHP-FPM and Nginx together?

Yes, the README states that images can run services such as `php-fpm` and `nginx` together with `supervisord`. It does not document detailed production signal handling or orchestration behavior.

## Sources

- [License: MIT](https://github.com/webdevops/Dockerfile/blob/master/LICENSE)
- [Project website](https://webdevops.io/projects/dockerfiles/)
- [README](https://github.com/webdevops/Dockerfile/blob/master/README.md)
- [Releases](https://github.com/webdevops/Dockerfile/releases)
- [webdevops/Dockerfile on GitHub](https://github.com/webdevops/Dockerfile)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/webdevops-dockerfile