An application should handle its own startup tasks — generating config, creating working directories, waiting on dependencies — in its own code, not by delegating them to custom container entrypoint scripts, configuration-management tools (Puppet, Chef, Ansible), or written deploy-in-this-order runbooks. Each outward delegation is a band-aid over an application that makes too many assumptions and "does very little to ensure a clean startup." Wrapper scripts carry real costs: they "add another layer of complexity to the deployment process for no good reason," they force a scripting runtime into the image, and they eventually "get out of sync with the application." Config-management ordering ("start the database before the app") is "nothing more then a band-aid covering up the larger problem." The rule: **deal with bootstrapping tasks as close to the application as possible, and avoid pushing the burden onto your users — who in the future may well be you.** Entrypoint scripts remain acceptable only for apps you don't control; for code you own, the fix is "good old fashion programming." **Cross-domain**: the same anti-pattern recurs wherever a fragile core is propped up by external scaffolding — onboarding docs that compensate for an unintuitive UI, manual runbooks masking missing automation, or a shell wrapper hiding a brittle CLI. Robustness belongs in the artifact, not the instructions around it. ## Source - [[12 Fractured Apps]] — Kelsey Hightower, Medium, Dec 14 2015