Skip to main content
Khal OS is a browser-based, macOS-inspired operating shell where packs — self-contained apps — run side-by-side for humans and agents. You author packs against the @khal-os/* SDK, wire them over NATS, and ship them into customer organisations through a release pipeline and catalog you’ll meet below.
Pack architecture: frontend package + optional Bun service + Helm chart, consumed by the khal-os shell

A pack is the unit of everything

Every pack is the same three things — a frontend package, an optional Bun service, and a Helm chart — declared together in khal-app.json and consumed by the shell at runtime. Some packs use only the frontend. Others wire up a full backend. A few bundle several frontends under one manifest.
khal-app.json
{
  "$schema": "https://raw.githubusercontent.com/khal-os/app-kit/dev/packages/types/src/khal-app-schema.json",
  "id": "settings",
  "name": "Settings",
  "version": "1.0.0",
  "description": "Desktop settings — appearance, services, SSH keys, keyboard shortcuts, system configuration.",
  "author": "Namastex",
  "permissions": ["nats:subscribe", "nats:publish", "system:clipboard"],
  "frontend": {
    "package": "@khal-os/pack-settings"
  }
}
No backend block. Scaffolds UI only. Ships as a single npm package.
See Example packs for the full reference list, and khal-app.json schema for every field.

The platform contracts

Every pack consumes a handful of platform contracts. You don’t build them — you call them.
CapabilityYour surface
AuthuseKhalAuth() returns {userId, orgId, role, permissions, loading}
Window managementThe shell launches, sizes, persists, and restores your pack’s windows
NATSuseNats() gives you a bridged client; subjects are scoped to your pack’s namespace
ServicesuseService() calls into your own backend service over NATS
Secrets and configDeclare env[] entries in khal-app.json; the platform injects values at install time
Multi-tenant isolationEvery pack runs inside its org’s boundary — permissions, data, NATS subjects

Agents are peers

Every pack exposes the same SDK to agents and humans. An agent can open your pack, drive its UI, and call its services — no separate API surface.

Packs are composable

Packs can publish to NATS subjects other packs subscribe to. A notes pack that emits changes is readable by a search pack, a voice pack, a summarizer pack — without coordination.

The release pipeline

From git push to a shipped artifact, the pipeline is the same for every pack:
1

PR to `dev` or `main`

ci.yml runs typecheck, lint, test, helm lint, and validates khal-app.json against the schema. All four gates must be green before merge.
2

Merge to `main`

release.yml reads the version from package/package.json, tags v${VERSION}, and cuts a GitHub Release with auto-generated notes. This is the publish trigger.
3

Artifacts publish

  • Frontend: @khal-os/pack-<name> → GitHub Packages (@latest on main, @next on dev).
  • Service (if declared): Docker image → ghcr.io/khal-os/pack-<name>-service:<version>.
  • Helm chart (if declared): OCI chart → oci://ghcr.io/khal-os/charts/pack-<name>:<version>.
See Publish your pack for the CI workflow map and failure modes.

The catalog

Published packs are indexed by the platform’s catalog — the component that turns your OCI chart into a one-click install for customer admins. From the platform side:
  • Every pack is registered with its manifest, version, and permissions after publish.
  • Customers browse the catalog per-organisation, see the packs they’re entitled to, and install them with one action.
  • Cross-org distribution is the catalog’s problem, not the FDE’s. You publish; the catalog routes.
On the FDE side, this means: do a good job on khal-app.json (accurate permissions, clear env[], real description) and your pack lands cleanly in every customer’s catalog. Nothing else is required. See Customer install for the customer-side handoff contract — what you hand over after publish.

Where the automagik toolchain fits

Khal OS is where packs run. The automagik toolchain is how you build them faster:

genie

Wishes in, PRs out — autonomous agent teams that scaffold and iterate on packs against the template.

omni

Omnichannel messaging. Agents inside your packs speak Slack, WhatsApp, Discord, email — one SDK.

rlmx

A research-grade reasoning loop for packs whose agents need to think before they act.
Automagik is how you build. Khal OS is where it runs. Every pack you’ve seen on this page was scaffolded, iterated, or refactored with the automagik tools.

Next

Clone the workspace

Get the khal-os workspace onto your machine.

Your first pack

Scaffold, run, and ship a pack end-to-end.