I shipped an endpoint to production that was never once able to run. Everything reported success. Nothing was serving.
I shipped a scheduled job to production and it could never once have fired. The route authenticated on a bearer header inside its own handler, but the middleware in front of it only knew about session cookies, so the request was rejected before its own auth ever executed. It answered 401 forever. A scheduler receives that and says nothing at all. I found it by hand-testing the live deploy, not from any test.
That is exactly the class of failure deploco is built around. A deploy command returning zero is not evidence that the thing it deployed is serving traffic. So there is a preflight before anything is dispatched, requiring the platform CLI to genuinely be on the path, and a health gate afterwards whenever the target declares an endpoint worth checking.
It also keeps the knowledge next to the execution. Each provider has a guide naming the credential it needs, the read-only command that proves access, the deploy procedure, and the ways it goes wrong. Credentials resolve from a real secret store at deploy time rather than sitting in a manifest, and the registry holds addresses rather than values.
The design decision I respect most is what it refuses to support. Fly, Render and Docker used to be listed. They passed validation at load and then threw partway through an actual deploy, so now a manifest naming one is rejected outright at the door. A target the tool cannot really execute is worse than one it has never heard of, because it reads as supported right up until the moment it is not.