Designing a cloud disconnect switch people dare to press
The right to leave only means something if it breaks nothing. This is the preflight, the honest list of what you actually lose, and how to come back.
Plenty of products advertise "no lock-in". The real test is not the wording on the pricing page — it is whether the product tells the customer the truth about consequences at the moment they press the leave button.
A preflight that tells the truth first
Before disconnecting, the platform lists every item that will break along with how to handle each one. The list is short and specific:
- Apps using a managed subdomain — a wizard migrates them to your own domain, and it must run BEFORE disconnecting.
- Backup target set to managed storage — switch it to disk, NAS or your own S3.
- AI running through the cloud proxy — point it at a local Ollama.
Nothing beyond those three, and that is the whole point. If this list grows over time, the architecture has drifted from its founding principle — and the list is the alarm.
What disconnecting means technically
Disconnecting revokes pairing and stops the agent: the API key is invalidated, cloud-side secrets are deleted, the environment is marked disconnected while billing history is preserved. The instance does not switch modes, because it never had a mode to switch out of.
Coming back has to be easy too
Reconnecting means issuing a fresh pairing token — exactly the action used the first time. A door that only opens one way is not a door, and people sense that even when they never intend to walk through it.