Skip to main content

xcon OS

xcon OS is a Debian-based appliance operating system. It exists for one reason: to make every guarantee the software on it gives — durability, crash survival, memory budgets, snapshot semantics — a guarantee on a known, measured, versioned stack instead of "whatever happened to be installed on the box".

It is not a general-purpose distribution you tinker with. It is an appliance: you install it, it comes up, and you manage it from one place — the web console. The operating system underneath is fixed, read-only, and updated as a whole.

The shape of it

  • Immutable base image. The operating system lives on a read-only image that is never modified in place — it cannot be half-updated or silently drift. Per-machine configuration (network, /etc overrides) and all runtime state live on a separate data partition and can change; the base OS underneath cannot.
  • A/B updates. Two system slots. An update is written to the passive slot and armed with a single atomic switch; if the new system fails to boot, the box falls back to the previous one on its own. Updates are transactions.
  • One management model. You administer the box from the web console (webadmin) and its CLI twin, xconctl. There is a single sudo-capable account (xcon); root is locked. The firewall is default-deny; only what you enable is open.
  • Debian underneath. The base is Debian stable. Security fixes come from Debian; you receive them as signed image releases on our update channel, never as ad-hoc package upgrades on the box.

What guarantees what

xcon OS is not a general-purpose distro you customize — it is a managed execution appliance for running stateful server software (such as xcon-db and xcon-mq). Drawing the line clearly:

  • xcon OS guarantees the substrate: a verified, immutable system image; transactional A/B updates with automatic fallback; data physically isolated from the OS; resource budgets; a default-deny firewall; and a continuously-checked desired state — it keeps a careless or hostile management action from making the hosted app unreachable.
  • The app guarantees its own correctness (durability, query results, protocol behavior) — and declares its own health, resource budget, and critical services to the OS.
  • Together they give a predictable, self-checking box: if any invariant breaks, the system surfaces it and, where it can, returns to a known-good state on its own.
  • You choose the hardware/VM, set the password, manage it through the console, and decide when to apply updates.

Two ways onto a machine

  • From the installer ISO — boot it, answer a few questions, done. See Install from ISO.
  • From a plain cloud Debian — one script converts any fresh Debian 13 cloud VM into xcon OS, with no provider APIs. See Install on a cloud VM.

Both produce the exact same xcon OS.