Name a platform, and I’ll name its device management. Windows? Microsoft Intune — and before it, SCCM, now called MECM, which nobody pronounces with confidence. macOS? Jamf — so taken for granted that Mac admins couldn’t act otherwise if they tried. iPhones and iPads? MobileIron, MaaS360, Workspace ONE — a whole zoo of MDM suites, all speaking the same Apple protocol. ChromeOS? The Google Admin console, elegant to the point of dullness. Android? No trouble at all — every Knox fleet, every carrier plan ships with management baked in.
And Linux?
Silence.
That silence is this article’s contention: the operating system that carries the world’s most demanding infrastructure — banks, telecoms, hospitals, industry — is the same one for whom nobody has seriously built desktop device management. Not commercially. Not freely. Nowhere with the seriousness that Jamf brings to Apple.
This is not embarrassing. This is an opportunity.
What device management actually is
Let’s not hide behind buzzwords. Device management is a discipline with a definite shape. A device is enrolled. It receives policies — what’s permitted, what’s mandatory, what’s forbidden. It receives software — automatically, silently, without the user hunting. It’s inventoried — who holds which device, in what state, at what revision. It’s patched — centrally directed, not left to the user’s goodwill. It’s monitored — is it online, healthy, compliant? And eventually it’s retired — securely, cleanly, with everything that entails.
All of it wrapped in an interface so self-evident that an administrator steers fleets of thousands without thinking per device. Apple set that bar with Jamf’s Self Service app: the user sees an app, taps, it’s there. Consistent. Friendly. Tidy.
By that yardstick we measure. Not by a lower one.
The market that exists
Let’s look honestly. The commercial products aren’t bad — they succeed because they deliver.
In the Windows camp Intune reigns, cloud-native, MDM over protocol, increasingly displacing classic SCCM/MECM, which arrives on-premises and agent-bound with its own heavyweight charm. Both together — co-management — is the reality in many shops.
For Apple, Jamf is the standard, flanked by younger challengers — Kandji, Mosyle, Addigy — all cloud-born, all exclusively Apple-focused. Run Macs in an enterprise and you barely escape this ecosystem.
Above it sits what’s now called Unified Endpoint Management: Workspace ONE (once AirWatch, presently under Omnissa), IBM’s MaaS360, Ivanti (which united MobileIron and Pulse Secure), ManageEngine Endpoint Central, Hexnode. Each tries to manage everything — Windows, Mac, mobile, occasionally Linux servers, seldom the Linux desktop. And ChromeOS rules the Google Admin console, plainly ideal for Chromebooks.
The common thread: this world revolves around Windows, Apple, and mobile. The Linux desktop is a footnote in it — if it’s mentioned at all.
The strange blind spot
Here it gets interesting. Nothing comparable exists for the Linux desktop.
Canonical offers Landscape — but it manages Ubuntu, chiefly servers, and thinly at depth. SUSE Manager rests on Salt, conceived close to infrastructure. Foreman with Katello provisions and configures, yet its heartbeat is the server room, not the desk. osquery, paired with Fleet, delivers visibility and compliance — but it interrogates state, it doesn’t declare it. Chef and Puppet carry server DNA; they can reach the desktop, but nobody taught them how Jamf feels.
None delivers what I set as the yardstick above: a device-management experience that takes the desktop seriously — profiles, application assignment, user preferences, default apps, MIME handlers, display layouts — and wraps it in an interface that’s a pleasure to use.
This isn’t a complaint. It’s a diagnosis. The gap exists because Linux belongs to no one — hence no one builds a product to sell for it. But that’s precisely why we can close it ourselves.
Back to open source, the hard way
One could wait for a vendor to notice the gap. One could buy a proprietary UEM and hope it takes Linux seriously someday. Neither is realistic. Whoever waits for suppliers outsources the definition of their own tool — and with it sovereignty over their own fleet.
So we build it. Open. With Ansible as the foundation, a relational database as the source of truth, and a plugin connecting the two. The hard way — because the hard way is the only one where you truly understand what you’re constructing.
Why Ansible is the foundation
I needn’t explain Ansible at length here. Agentless, SSH, idempotent, declaring state rather than procedure — I’ve made that case elsewhere. For device management it’s still worth naming: it’s the only widespread automation that doesn’t presuppose a managed daemon running on the target. A box that speaks SSH is manageable. Full stop.
But Ansible is the foundation, not the ceiling. It declares state beautifully — it doesn’t model it. And that’s where the real problem begins.
Where YAML reaches its limits
A small fleet tolerates YAML. Ten boxes, one inventory, a handful of group variables — done. But a real fleet isn’t linear. It’s a fabric of devices, owners, roles, profiles, sites, departments, exceptions, application bundles, and configuration fragments, all relating to one another. The same app across three profile types, but only at two sites, except for the one device that warrants a special carve-out.
YAML anchors and aliases are pretty. They are no substitute for referential integrity, joins, constraints, normalisation, and transactions. A flat YAML inventory buckles under its own weight the moment the matrix of devices × profiles × exceptions goes three-dimensional.
This demands a real relational database. PostgreSQL. With a considered schema: devices, owners, profile classes, applications, configuration snippets, sites, exception grants, enrollment state. Foreign keys enforcing relationships. Views answering complex questions in a single query. And a self-written lookup plugin that translates those rows, at runtime, into variables Ansible understands — relations becoming Jinja2 templates.
Truth lives in one place. Templates derive from relationships, not copies. That’s the difference between an inventory and a model.
Why not just extend NetBox?
A fair objection — and I know it, because my own toolkit already ships NetBox roles. NetBox is, in essence, what I’ve just described: PostgreSQL beneath, a web GUI atop, a plugin system, custom fields, tags, relationships, REST and GraphQL. A single source of truth, beloved by network engineers, and deservedly so.
Yet NetBox has a frame — DCIM and IPAM — and its maintainer guards that frame with enviable rigour. Feature requests that don’t fit the network-and-datacentre picture routinely fall through the sieve. That’s no flaw. It’s the reason NetBox stays excellent rather than sprawling.
Desktop lifecycle, however, is a different domain. Profile assignment, application bundles, user preferences, MIME defaults, display layouts, enrollment state — these don’t model naturally onto tenants, sites, racks, and VLANs. Two paths remain: a standalone schema, built for the desktop, that grows its own web GUI in time. Or a NetBox plugin that carries the desktop models without touching core. Both legitimate. Banking on upstream core acceptance would be naive. My instinct says: first the standalone, purpose-built truth — and should the domains reconcile one day, migrate it as a plugin to where it belongs.
The web GUI that comes eventually
I’ll admit it openly: at the beginning there’s no gleaming portal. There’s SQL, the command line, and the plugin. That suffices for whoever builds — and for whoever knows what they’re doing. But device management should eventually be operated by people who’d rather not read YAML. So the web GUI comes in time: CRUD over the schema, drag-and-drop profile assignment, a view per device, a view per user, a view per fleet. Until then the schema is the truth — and the truth is structured well enough that any future interface merely layers atop it.
Everything in files — why Linux is predisposed
Now the deeper architectural point, and it’s the real lever.
Linux is configured in files. Dotfiles in the home directory. /etc for the system. systemd units as text. MIME handlers as text. Foot, Kitty, Waybar — text. And Sway, the tiling window manager I roll out through my own Ansible role: pure text configuration. Anyone who has felt a mode switch, a fullscreen, a tile snap into place with a keystroke understands why that’s not merely efficient — it’s beautiful. Almost magical. Suddenly a window slides aside, another tiles beside it, and everything fits — no mouse, no menu.
I won’t linger on Sway. The point is larger. In GNOME, settings live in dconf — a binary-affine store that yields to templating only reluctantly. KDE uses ini-like files, but with its quirks around kded and kwriteconfig. Sway, meanwhile, is pure text — and pure text is Jinja2 territory. One role, one template, one render — done. That’s precisely why the Sway/Wayland stack is so attractive to Ansible: everything defined is a file, and every file is a template.
That’s no accident. It’s the architectural precondition Linux brings to device management that proprietary systems offer only in part.
The Manage-My-Network toolbox
I’m not arguing from theory. Under imp1sh on GitHub lies my Ansible collection ansible_managemynetwork — open, Debian- and OpenWrt-facing, grown over years. Among its roles: Sway and Waybar, but equally Zabbix agent, SNMPD, Restic and Borgmatic for backups, patchday, SSH keys, users and groups, MOTD, Chrony, DNS, firewall. The exhibit: the pattern works. None of it theoretical. All of it deployed — often enough under pressure.
This collection is the seed. The device management I sketch here is the tree.
Love for detail — better than Apple
Now it gets presumptive. Now it gets honest.
We’re not talking about recreating functionality. We’re talking about surpassing the experience. Consistent, friendly, tidy — as Apple pioneered, but without the paternalism. Defaults that respect the user. A fleet so effortless to steer that an admin governs thousands of devices without thinking per device. Monitoring integration that grows along: every device automatically rolls out its node exporter, its Zabbix agent, its SNMPD — the fleet becomes observable without anyone manually enrolling it.
The actual project isn’t to invent a distribution. It’s to continually refine an existing publication. Polish. Again and again. So consistently that eventually no one honestly wishes they had macOS or Windows back. Lol — but earnestly meant.
The distro decision
Which publication? Here it gets concrete, and I won’t dodge.
Debian is the natural anchor — my collection targets it, it’s bedrock-solid, and that constancy is a gift to a fleet that deserves stability. The price: stable can be too tame for a glossy desktop. The remedy is pragmatic — backports, Flatpaks for current applications, selectively testing. Not dogma, mixture.
Fedora is the lure: fresher Wayland, current Sway, PipeWire up to date, upstream-close. Those wanting a brisk desktop find little to fault here. The price is higher cadence — churn that can fatigue a fleet if you’re not careful.
openSUSE and Arch derivatives stand in the room too; NixOS is intellectually tempting but maintenance-wise a language of its own. Balance it honestly: for continual polish without fires, Debian is the ground you build on most calmly. Fedora stays the trial for those who rate freshness above calm. I lean Debian — and I say so openly, because the collection has already chosen it.
Integration that grows along
A fleet that enrols itself is only half done. The other half is observability. The instant a device is onboarded it receives its exporter, its agent, its backup configuration — all from the schema, all templated. Prometheus scrapes, Zabbix records, Uptime Kuma pings. Backups run with Restic or Borgmatic — encrypted, deduplicated, without anyone thinking about them. Retirement withdraws cleanly: keys gone, inventory archived, monitoring silenced. The entire lifecycle, wired.
How enrollment actually works — honestly
So this isn’t illusion: Ansible pushes by default — controller to host over SSH. Roaming laptops are rarely reachable when you need them. Hence pull mode. ansible-pull, driven by a systemd timer or cron, periodically pulls the declared state from the repository. A lightweight controller — be it AWX, be it a small runner — coordinates what’s outstanding. Enrollment then amounts to: a device, a token, a first pull. No sorcery. Just consequence.
That’s more honest than the promise of classical MDM check-ins — and for an open-source fleet, robust enough.
Why this makes sense
Someone may wonder: are you rebuilding Jamf for Linux? Yes and no. Yes, because the aspiration is the same — fleet management that takes the desktop seriously. No, because the path differs: not a product you buy, but a model you own. Open source, relational, text-driven, with love for detail.
The gap exists because Linux belongs to no one. That’s precisely why we can close it — without permission, without another company’s roadmap, without fear that a vendor pulls the plug. That’s not a drawback. It’s the condition of possibility.
If you operate a Linux desktop fleet — or plan one — and have wondered how it’s meant to work without leaning on proprietary UEM: let’s talk. No sales pressure, with an eye on the long term. Write to contact@libcom.de. We’ll take stock — honestly, traceably — and think through together whether and how this approach suits your fleet.