What a Deploy You Actually Control Looks Like
Most teams cannot explain what happens between git push and live. That gap is where the outages and the vendor lock-in hide. Here is the version I run.
Ask most teams what happens between git push and the site being live, and you get a shrug and a platform name. That shrug is the problem. If you cannot describe your own deploy, you do not own it. You rent it, and the landlord can change the locks.
I run the whole portfolio on infrastructure I control, so I had to answer this question for real. Here is what a deploy you actually control looks like.
You can name every step
A controlled deploy is one you can draw on a napkin. Code lands, a build runs, an image gets produced, the new version starts, health checks pass, traffic moves over, the old version drains. Nothing in that list is exotic. The point is that I can name each step and change any of it. When something breaks at 2am, I am debugging a system I understand, not filing a ticket with a company that will answer on Tuesday.
Rollback is one command, not a prayer
The test of a deploy is not the happy path. It is the bad one. If the new version is wrong, how fast do you get back to the last good one, and how sure are you that you did? On a controlled setup, rollback is boring: the previous image is still there, you point at it, traffic moves back. On a managed black box, rollback is often a support conversation while your customers watch the error page.
This is the same logic I wrote about in I host it myself. Owning the boring parts is what buys the calm.
The build does not depend on someone else's mood
Plenty of "our site is down" mornings are really "our build provider is down" mornings. When the build lives on hardware I run, the only thing that can stop a deploy is my own code. That is a much shorter list of failure modes, and every item on it is mine to fix.
Why this matters across twenty companies
At one product, a controlled deploy is a nice-to-have. Across a portfolio, it is the difference between one operations playbook and twenty vendor relationships. I built HostSSH around exactly this idea: servers and deploys that cannot be held hostage, so every company on top inherits the same predictable path to live. The operations cost gets paid once and amortized across all of them, which is the pattern behind how I run a portfolio solo.
You do not need twenty companies to want this. You need one deploy you can explain, one rollback you trust, and one fewer company that can change the rules on you. Start by drawing the napkin. If you cannot, that is your first task.