KINGAI OS Edge

What Edge is for

Edge targets small appliances, gateways and offline-first nodes that sit in a corner and keep running when the network does not. It is still in planning. Everything below is design direction, and none of it counts until a real image and hardware testing exist.

Design direction

• Small image footprint for hardware with limited storage and memory
• Offline-first behavior: queue work locally, sync when connectivity returns
• Secure updates, device cohorts and remote management (design goals, not shipped features)
• amd64 and arm64 builds; arm64 is a target architecture with no validation record yet
• TPM, secure-element and secure-boot options where the hardware supports them

See the four-edition roadmap →　See release history →

Positioning: sealed into a device, steady without a network

Edge is aimed at a particular kind of hardware: small gateways and dedicated terminals tucked into shops, warehouses, equipment rooms and outdoor enclosures. Storage is tight, memory is limited, the network comes and goes, and nobody may visit the device in person for months. For hardware like that, an operating system's most important quality is not feature count. It is small size, no data loss while offline, and updates that can pick themselves up after failing.

That is why the Edge design order is survival first, management second: collect data locally and hold it steady, sync to the center when the network returns, and make every update either complete fully or roll back to the previous working state — never stop halfway. All of this is still design entries in the product documents. This section unpacks them one at a time, and each carries the same status: not yet implemented.

The planned capabilities, unpacked

Small image footprint

Device storage and memory are both scarce, so the image gets trimmed to what the device actually uses. The goal is a small footprint; real numbers wait for a real image, and the planning stage publishes none.

Offline queue

While the network is down, collected data and pending events queue up locally; when connectivity returns, they sync to the center in order. Unstable site networks are the normal case, and this mechanism decides whether a few offline hours quietly erase data.

Immutable and dual-partition updates

Where the hardware suits it, the system partition stays read-only, updates are written to a second partition, and a failed boot switches back to the old one automatically. For an unattended device, that is far more realistic than dispatching a technician after a bad update. Applicability depends on the hardware; the documents say where suitable.

Signed device commands and canary cohorts

Remotely issued commands must arrive signed, and anything from the wrong source gets refused. New versions roll out to a small canary cohort first and go fleet-wide only after observation. Together these are the foundations of fleet management — and today they are design targets.

Secure boot and TPM options

Secure boot, a verified boot chain and TPM or secure-element support all depend on what the device hardware itself offers. The documents list them as options, not standard equipment, and this page makes the same limited promise.

Fail-safe recovery

After an interrupted update, a power cut or a corrupted configuration, the device must return to a working state rather than a brick. Recovery paths get their own interruption tests before release — one of the gates below.

Why there is no ISO yet: four release gates

• An independent ARM64 hardware matrix — arm64 is currently a target architecture with zero verified machines
• Remote offline and reconnect testing — proving the queue-and-sync design actually behaves as drawn
• OTA interruption and rollback testing — pull power and network mid-update, and the device must recover on its own
• Supply-chain signing and package license review — every package in the image accounted for, source and license alike

None of the four gates has been passed, so Edge has no version number, no ISO and no download button. The official catalog states it directly: no hardware, OTA, fleet management or ARM64 support is claimed.

Current progress, stated plainly

Publicly: planned, full stop. On the internal experimental line, the engineering team has built amd64 Edge experimental images in the Debian 13 direction and kept build records — but the images were not retained, there is no download, and no firmware boot validation was run on them. An experimental build and a public release have four gates between them, and anyone offering a KINGAI OS Edge package today is not offering an official one.

See the four-edition roadmap →　See the version log →　See the published Server preview →　Follow progress in Issues →