Минус 500 MB в Docker-образе — это не про эстетику, а про дисциплину команды.

Минус 500 MB в Docker-образе — это не про эстетику, а про дисциплину команды.

Когда backend-приложение разрастается до 1,5 GB, в прод уезжает не продукт, а свалка: dev-зависимости, кэш, тестовые файлы, сборочный мусор. И пока всё «работает», это обычно никто не считает проблемой. Пока не начинается скандал: медленные сборки, долгий деплой, лишняя нагрузка на CI и нервный тик у DevOps.

Что здесь важно:
- каждый лишний слой = дороже сборка и доставка;
- каждый ненужный пакет = больше поверхность для ошибок и уязвимостей;
- каждый мегабайт = еще одна причина, почему масштабирование тормозит.

Практика простая: смотреть не на «собралось ли», а на состав образа. Мультистейдж-сборка, чистка зависимостей, отказ от мусора после build, минимальный base image — это не оптимизация ради красоты, а управляемый расход инфраструктуры.

Если образ толстый, у вас уже есть KPI, который молча ухудшает экономику. И обычно проигрывают те, кто первый год называл это «неприоритетной технической деталью».