Columbia Games · WordPress / 14 May 2026
A custom WordPress image should bake in the environment, not the entire project
A custom Docker image can quickly become a dumping ground. Runtime dependencies, project files and developer convenience tooling needed clear boundaries.
Situation
Once a custom WordPress image was chosen, the next question was what should go into it. It is easy to copy everything into the image, from plugins to project code, and treat the result as one large layer. That is convenient initially, but every small file change then triggers an image rebuild and runtime concerns become mixed with application content.
Approach
I treated the image as the runtime base. Required PHP and Apache settings, system dependencies and WP-CLI were baked in, while project files stayed mounted or remained in layers managed by the repository. The container image therefore described the environment the project runs in rather than which project commit happened to be under development.
Outcome
Developer iteration became faster and image caching became cleaner. A plugin or theme change no longer required rebuilding the entire runtime image. The same boundary later helped CI and production deployment design: a runtime image and a release artifact should not be treated as the same concept.