Multi-Tenant SaaS From a Single-User Tool: The Cloud Migration

A tool built for a single user on a single machine has, almost by definition, no data isolation requirements, there's only one tenant, so there's nothing to isolate from. The moment a second customer shares the same infrastructure, that entire category of assumption stops being safe. A real migration from single-instance tool to multi-tenant SaaS moved through distinct, sequenced stages rather than one big rewrite: first, a multi-tenant WebSocket hub service as the new foundation. Then a phased migration where existing single-instance runners sync their state into the cloud hub rather than a hard cutover. Then, critically, an HTTP-over-tunnel proxy built with an explicit allow-list that fails closed, a redundant deny rule enforced on the runner side, a request body size cap, a CRLF injection guard, host-rewrite handling, and explicit JWT stripping before requests cross the tunnel boundary. Finally, per-plan tenant quota enforcement. The sequencing matters as much as the individual pieces. Quota enforcement went in at the same time as multi-tenancy, not as a follow-up, because unbounded or unbilled cross-tenant resource use is a launch-blocking bug the moment more than one paying customer shares infrastructure, not a nice-to-have for later. And the tunnel/proxy layer was treated as its own dedicated security surface from the start, with the full checklist above, rather than an incidental implementation detail bolted onto the migration. If you're planning a similar migration, the honest scoping is: this is not "add a tenant_id column." It's a new security surface (the proxy layer), a new resource-accounting system (quotas), and a phased data migration, three separate pieces of real engineering work, not one.