We sell billing, the control panel and monitoring separately because each one owns different facts
Zephyr, kstack and Standby are three products, not a suite. The reason is a rule about who owns which fact, and it is just as useful if you only ever run one of them.
A hosting company ends up running three kinds of system whether it plans to or not. Something bills the customers. Something builds and runs what they bought. Something watches the machines and wakes a person up when one of them stops answering.
The usual way to make those work together is a suite: one vendor, one bundle price, one release train, and a lot of data copied between the parts. We build all three, and we deliberately do not sell them that way. Zephyr is billing, kstack is the control panel and the agent on each server, and Standby is monitoring and on-call. Each is bought on its own.
The reason is not commercial packaging. It is a rule about data.
The thing that breaks is the copy
Most of the pain in a hosting stack is two systems holding the same fact. The plan exists in the billing system and again in the panel, and somebody changes one. The list of servers lives in the panel and again in the monitoring tool, and a new server is added to one of them. Nothing errors. The two copies just drift, and the drift surfaces as a customer sold something that cannot be built, or a machine that nobody was watching.
So the rule is: every fact has exactly one owner, and the others ask it rather than keep their own version.
- Zephyr owns the commercial facts: the catalogue, invoices, the ledger, the customer.
- kstack owns what is placed on a machine and its lifecycle: sites, DNS zones, mailboxes, databases, certificates, storage buckets.
- Standby owns the physical facts about a machine: whether it is reachable, its patch state, its exposure to known vulnerabilities, and whether its backups have been proven.
Drawn that way, the products are separate because the facts are separate. A billing system has no business measuring a server, and a monitoring system has no business knowing what a customer paid.
What actually moves between them
With one owner per fact, very little has to cross between the three, and each crossing goes one way.
- From Zephyr to kstack: a paid order. A paid invoice becomes an account, a subscription and its resources, against the plan that was bought. This integration is experimental today, and we label it that way on our own pages.
- From kstack to Zephyr: which plans each location can build. kstack publishes plan kinds, sizes and measured facts per location, and Zephyr sells that rather than a list somebody retyped. A location appears for sale only when a server there can actually serve it. That is the practical form of an argument from an earlier post: a checkout should refuse what it cannot build.
- From kstack to Standby: alerts. kstack raises its alerts as incidents in Standby, and pushes its serving probes.
- From Standby to kstack: what the machine is actually doing. Reachability, patch state and vulnerability exposure come back, and kstack displays them rather than measuring them a second time.
Everything else stays where it is. kstack implements no billing of its own, on purpose. Standby watches machines whoever put them there, not just the ones kstack built.
Each one stands on its own
Because the agreement is about who owns what, it is as useful with one product as with three. That is the test we hold them to.
- Zephyr without kstack, on its Hosting Provider edition, provisions into other panels too: Enhance, cPanel, Plesk, DirectAdmin, Proxmox, Hetzner Cloud and OpenStack. We mark each by how far it has been proven: Enhance verified, kstack experimental, the rest beta.
- kstack without Zephyr needs something to bill, because it has none. Anything else can drive it through the provisioning API, which is public and documented. The kstack panel itself uses no private endpoints that you cannot; if the panel can do it, so can your script. That rule is also what keeps replacing any one of the three possible later.
- Standby without either watches machines whoever put them there, Linux and Windows, with one agent.
Each runs on hardware you already have: Zephyr on your servers with your own PostgreSQL, kstack on the servers you run, Standby on your own Ubuntu, Debian or Alpine server. There is no bundle price, no lock-step release train, and no discount for taking all three. Zephyr is licensed per install, kstack per node and Standby per endpoint.
Updates arrive the same way
Separate products do not mean three different update stories. All three come down the same release edge: licence-gated, signed with Ed25519, and checked against a pinned key before anything is swapped in. Nothing is fetched from a mirror and trusted because it downloaded cleanly. For kstack, your control plane takes each release through that channel and your servers then update from your control plane.
The install command is in your portal after purchase, two lines carrying your licence key, rather than a public one-liner. That is also how the licence gets onto the machine.
If a licence lapses
This is where the one-owner rule matters most, because each product stops only the things it owns. Nothing already running is switched off.
| Product | Keeps running | Stops until renewed |
|---|---|---|
| Zephyr | Billing and supporting your existing customers | New orders, updates |
| kstack | Your servers and sites | Adding servers, updates |
| Standby | Paging, monitoring, the status page | Adding hosts, updates, fetching vulnerability data |
A billing system that stopped invoicing because its own licence lapsed would be punishing your customers for a conversation between you and us. A monitoring system that stopped paging would be worse.
What it costs you
Three products are three things to install and keep updated, and the Zephyr to kstack handover is still experimental. We would rather say that than sell a bundle that hides it. We are also the first customer: lbreeze's own hosting runs on all three, so when one of them is wrong we find out the way you would.
The short version
- Give every fact one owner, and make the others ask for it instead of copying it.
- Between billing, panel and monitoring, only four things need to move: paid orders, buildable plans per location, alerts, and the machine's real state.
- A product that is useful on its own is one you can adopt, or replace, one piece at a time.
- When a licence lapses, nothing already running should stop.
If you are weighing which of the three to start with, the software overview puts them side by side.
- zephyr
- kstack
- standby
- architecture
Read next
- SoftwareWhy a hosting control panel should never log in to your servers
A panel that reaches into servers to change them is a single key to every machine, and it only knows what it did, not what is there. Turn the arrow round.
- SoftwareAn overdue invoice should follow a timetable both sides can read in advance
What happens to an unpaid invoice day by day, from the first reminder to termination, and what a customer and a hosting company can each do at every step.
- SoftwareA checkout should refuse the order it cannot fulfil
Billing systems take the money first and provision second. That ordering is correct, and it means every gap in your provisioning becomes a charge you have to explain and a refund you have to make.
- SoftwareA rate limit and a spend cap should not return the same status code
429 means try again shortly. 403 means stop. Return 429 when someone has hit a monthly budget and every well-behaved client you serve will retry, politely and forever, against a wall.


