A new module built with nwidart/laravel-modules worked on every laptop, then production threw Class not found for its service provider right after deploy. The module's composer.json was never merged into the root autoloader in the image build, and an authoritative classmap froze the result.
Most deploy outages come from the same handful of gaps: no readiness check, killed in-flight requests, a migration the old code cannot survive, or no fast way back. This is the checklist we run before every release, with the reasoning behind each item.
Our deploy script printed a pg_dump authentication error, then happily ran migrations and switched traffic to a half-migrated release. Bash does not stop on errors by default, and a pipe hid the failure even where we checked. Here is the strict-mode setup and its traps.
Our deploy ran composer update on a 2 GB server until the resolver ran out of memory. Raising the limit let the OOM killer take MySQL instead. Committing the lock file exposed a second bug: it had been resolved on PHP 8.4 for a PHP 8.2 server.
Data scientists promoted a new churn model by setting the champion alias, as the newer MLflow docs recommend. Our deploy script still loaded models:/churn/Production, which pointed at the old version. Stages are deprecated; we moved the whole pipeline to aliases and added a promotion check.