Client Hosting Mode

Client Hosting Mode turns unused capacity on a server you already pay for into something you can sell. You define packages (a memory, CPU, disk and app-count limit, and a price), add your own clients against them, and DeployOS enforces the limits with real Docker resource caps — not a number on a page. Requires a Pro license (up to 3 clients) or Agency (unlimited clients, plus a white-label Client Portal with no DeployOS branding) — see License Plans & Billing.

How it's split between the website and the app

Account and billing management happens at mydeployos.com → Dashboard → Client Hosting. Everything that actually touches a server — deploying, applying resource limits, suspending — happens only in the desktop app, which is the one thing in DeployOS that ever opens an SSH connection. The website writes down what you want to happen; the desktop app picks it up and does it the next time it's open. Nothing about a client's app, server, or credentials ever passes through DeployOS's own servers beyond that request queue.

Setting up a package

On the website, define a package: name, price, billing interval, and real limits — CPU, memory, disk, and a maximum number of apps. The limit isn't a label. Assigning a client to a package enforces a real Docker --cpus/--memory cap on their app once it's applied.

Capacity is computed the same way on the website and in the desktop app, capped at 90% of a server's real RAM — so you can't oversell a server's capacity from either side, and the same math that warns you on the website is what the desktop app actually enforces.

Adding a client and assigning them

1. Add a Client (their name and email) on the website.
2. Create a Client Service — pick the client, a package, which of your servers it runs on, and (optionally) a domain. This queues a request for your desktop app to pick up; nothing happens on the server yet.
3. Open the Clients page in the desktop app and click Sync now to pull the request.
4. Apply it. If the client has already chosen what goes on their service (see below), a single button sets it up automatically. Otherwise, assign it to an app you've already deployed yourself.

Letting clients set themselves up

Clients get their own login, separate from your own DeployOS account, at mydeployos.com/client/login — a magic-link sign-in, no password. From their dashboard they can:

• See their own services, status, and invoices
• Choose WordPress or upload their own files (a .zip of a site, or a single image/page), and set a domain

Their browser never touches your server — the choice they make is written to the same request your desktop app already picks up. Once you apply it, the WordPress site or their uploaded files get deployed and wired to their domain automatically; you don't need to build anything yourself first.

Uploaded files are encrypted at rest until your desktop app downloads and places them on the server.

Billing

Billing is manual: you tell clients how you want to be paid (a payment link, bank details, whatever you already use) and mark invoices paid yourself once they come in. DeployOS doesn't process a card or take a cut.

What is automatic is the entitlement lifecycle — a client moves through active → grace → suspended on its own, based on overdue invoices, with no status-flipping by hand:

• An open invoice past its due date moves a service into a grace period (a few days by default).
• Still unpaid after that, the service is suspended — visitors to the client's site see a page you control instead of it silently breaking.
• Marking the invoice paid (or restoring manually from the Clients page) brings it back immediately.

Suspension is enforced by a small container that runs permanently on the server once you opt into it — it polls the website directly, so suspension still takes effect even if your desktop app isn't open at the time.

What this doesn't do yet

Automatic card charging on a client's behalf isn't built — billing stays manual, by design, so you can use whatever payment method you already have set up with your clients.