Docker sprawling to nine files
Nine Dockerfiles across five apps with dev and prod variants, consolidated to two by selecting the app through build args.
Two copies drifted
One idea kept by hand in two places — schema and migration, dev and prod, app and app.
No single bad call, just reasonable decisions stacking. This app needs its own Dockerfile. Dev needs different build args than prod, so add a .dev variant. Repeat across web, admin, super-admin, mobile and backend and you have 9 files, and any shared build change means editing half of them.
Down to 2 now — one backend, one frontend — with build args selecting the app. The three frontend apps share almost their whole pipeline and never needed separate files. In a monorepo where several things share a build process, default to one parameterized Dockerfile per logical component rather than one per deployable. This is downstream of not planning the infra shape up front.