Slots & capacity
The unit that makes hosting portable and safe to pack — size an app, place it on a node with hard resource caps, meter it, and move it.
Slots & capacity
A Slot is one movable, resource-capped unit of hosting capacity — the home for a single workload (an app, a worker, a database). Instead of reasoning about servers and SSH sessions, you reason about Slots: a Node offers a fixed number of them, you fill the ones you need, each one has hard limits so neighbors can't starve each other, and you can pick a Slot up and move it to another Node.
Slots do three jobs at once: they're how you measure capacity, how you meter/bill, and how things move.
The vocabulary
| Term | Meaning |
|---|---|
| Slot | One capped unit of capacity where a single workload lives. |
| Rack | A Node seen as its set of Slots ("this Rack has 20 Slots, 12 filled"). |
| Workload / App | What fills a Slot. |
| Fleet | All your Racks together; the Slot Board shows the whole fleet. |
(Full definitions in Concepts.)
Slot sizes and what they actually enforce
When you deploy into a Slot, HostSSH enforces hard Docker resource caps on the container. Four sizes, each a multiple of the base envelope:
| Size | vCPU | Memory | Max processes (PIDs) | Multiple |
|---|---|---|---|---|
s | 0.5 | 512 MB | 256 | 1× |
m | 1.0 | 1 GB | 512 | 2× |
l | 2.0 | 2 GB | 1024 | 4× |
xl | 4.0 | 4 GB | 2048 | 8× |
These are enforced by --cpus, --memory, and --pids-limit on the container — a real isolation
boundary, not a billing label. The same numbers are the single source of truth in the Agent
(Go) and the control plane (TypeScript), and a drift guard fails the build if they ever diverge.
An unslotted deploy (no
--slot-size) runs with no caps — fine for a box you own entirely. Use Slots when you're packing several apps onto one Node, or reselling capacity.Buy Docker Space one Slot at a time from Billing or Pricing. Shared S is $3/mo; Reserved XL is $64/mo. Hard caps, daily encrypted backup, named volume you can move. Buying Space never changes your plan.
Slot classes: burstable vs reserved
Two classes make a deliberate trade between density and guaranteed performance:
- Burstable — shared and oversubscribed, for workloads that are mostly idle (classic shared WordPress). Many Slots share the machine fairly, so a smaller box packs in a lot of them.
- Reserved — a guaranteed slice, for production apps and databases. Each Slot gets a hard envelope so performance is predictable and billing is honest. Fewer Slots per box, but each is yours.
The platform recommends a Slot count for each Node from its CPU/RAM/disk (tunable per Rack). Roughly,
a 4 vCPU / 8 GB box lands around 20 Slots and an 8 vCPU / 16 GB box around 50 — which is why two
machines can offer different counts. The recommendation logic is recommendedSlotCapacity() in
control-plane/web/lib/slots/types.ts.
Two numbers, two jobs — don't confuse them. The size caps above (0.5 vCPU / 512 MB for
s, etc.) are what your container is actually limited to. Separately, to decide how many reserved Slots a box can hold, the platform reserves roughly 1 vCPU / 2 GB / 25 GB of planning headroom per reserved Slot — a capacity-planning/billing figure, not the per-container cap. You deploy against the size caps; the reserved envelope only sizes the board.
Deploying into a Slot (live)
Deploy-into-a-Slot is live. On the CLI:
$ hostssh deploy --name shop --source ./shop --slot rack1/3 --slot-size m
or pick a Size in the dashboard's Deploy drawer. What happens:
- The scheduler resolves a free Slot of the right size on the Node you chose (or bin-packs onto the first Rack with capacity).
- The deploy is created and the placement is recorded atomically — no orphaned Slots if something fails mid-flight.
- The container is tagged with its Slot (
hostssh.slot=rack1/3) and launched with the size's caps. - On success the App shows on the Slot Board as occupying that Slot. One workload per Slot — HostSSH refuses to double-book.
If a slotted deploy fails, the Slot is held (not silently freed) so you can inspect and retry or release it deliberately.
The Slot Board
The Slot Board at /slots shows your fleet the way you think about it: each Rack is a grid of Slots,
filled ones colored by what they hold, empty ones open. You see at a glance how much capacity each
Node has and how much is free. It reads live placement data (Postgres when connected, seeded
in-memory otherwise).
Moving and metering
- Move a Slot — capture one workload and restore it into a free Slot on another Node (a single-workload migration between machines).
- Move a whole Rack — the same operation at its widest scope: drain every Slot off a Node onto others, then retire the box. This is how a full-server move or a machine-renewal migration is expressed.
- Meter a Slot — size-weighted Slot units roll up per-Rack and fleet-wide into billable units and utilization, mapping onto plan tiers (burstable → shared, reserved → dedicated).
For the product rationale, reseller/MSP packaging, and how Slots map onto the codebase, see the Slots product spec.
Next steps
- Deploy an app into a Slot → Deploying apps
- Move a whole box → Migrating to HostSSH