What Sextant does differently,and what it does not do.

Two comparisons. The first is about the way of working, the second is about the products you are probably holding this next to.

From clicks to commits.

Not a second way of working next to the console. The button in the console writes the commit, so there is one history and it is yours.

Where the truth lives
Clicking in a console The vendor’s database
Sextant A file in your own git
How a change is approved
Clicking in a console An action log, after the fact
Sextant A review, before it lands
When a laptop drifts
Clicking in a console Noticed at the next report
Sextant It cannot: the laptop rebuilds
Rolling back
Clicking in a console Redo it by hand
Sextant Boot the previous version
What an auditor gets
Clicking in a console A screenshot of a screen
Sextant The commit that caused it
Clicking in the console
Clicking in a console Leaves no trace outside the vendor
Sextant Writes a commit like any other change

Not just managed. Provable.

Traditional MDM sends commands to a device and records whether they seemed to land. Sextant describes what the device should be, and the device builds itself into that. The difference shows up everywhere.

How configuration is defined
Traditional MDM Toggles in a console, policy by policy
Sextant One document in your own git
What reaches the device
Traditional MDM Commands, applied best effort
Sextant A complete system it builds itself
When a device drifts
Traditional MDM Noticed later, remediated if you are lucky
Sextant It cannot: the device rebuilds to the definition
Proving what runs
Traditional MDM A report of what was intended
Sextant A hash of what is actually running
Provisioning a laptop
Traditional MDM Enrol, wait, layer policies, check
Sextant Image once, at the revision its ring is pinned to
Rolling back
Traditional MDM Reverse the change and hope
Sextant Boot the previous generation
What the vendor can do
Traditional MDM Reach into the device over a command channel
Sextant Nothing: there is no inbound channel

Where Sextant sits.

Sextant does one thing: NixOS workstations you run yourself. If you manage phones and Windows laptops, the products below do that and Sextant does not.

Runs on your own infrastructure
Sextant
Microsoft Intune
Fleet
Source you can read
Sextant All of it, EUPL 1.2
Microsoft Intune
Fleet Core is MIT, some features are paid
What describes the fleet
Sextant One document in your git
Microsoft Intune Policies in a console
Fleet YAML in your git
What reaches a laptop
Sextant A complete system it builds itself
Microsoft Intune Commands, applied best effort
Fleet Commands and profiles
Devices covered
Sextant NixOS workstations
Microsoft Intune Windows, macOS, iOS, Android
Fleet macOS, Windows, Linux, iOS, Android
Evidence for an audit
Sextant Exported per control, from check-ins
Microsoft Intune Reports in the console
Fleet Live queries and reports

Checked August 2026 against public documentation. If we have something wrong, tell us and we will correct it.

One document for every laptop.site.audit.

Take it, run it, help build it.

The software is yours under the EUPL 1.2 and needs nobody’s permission. What the project needs is people: a laptop model we have never imaged, a language nobody has translated, a bug found by running it for real.