lbreeze

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.

Kosta
lbreeze · 10 October 2026

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.

  1. 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.
  2. 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.
  3. From kstack to Standby: alerts. kstack raises its alerts as incidents in Standby, and pushes its serving probes.
  4. 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.

Read next