Config as code at the endpoint: the last layer managed by clicking

The endpoint is still managed through a console where somebody ticks a box and nobody can reconstruct afterwards who ticked it, when, or why.

What config as code means at the endpoint

Device configuration lives as a declarative file in the organisation's own version control and is applied by its own pipeline. Not as an export from a tool, not as a backup, not as documentation alongside the actual state. The file is the state.

Three things follow that can only be simulated in the console world: a single source of truth, an approval path with a second pair of eyes, and a change log the organisation owns rather than rents from a vendor.

Why this is more than convenience in regulated environments

Change control

Who may change what, who approved it, when it took effect: in a repository those are properties of the procedure rather than questions put to an administrator's memory. That covers statutory change control obligations without additional tooling and maps onto IT-Grundschutz modules ORP.4 and OPS.1.1.5.

Auditability

An auditor does not ask whether a setting is applied. They ask since when, on what basis, and who reviewed it. Those three answers sit in the repository history without anyone reconstructing them afterwards.

Reproducibility

A state that exists as a file can be reproduced: after a mistake, after a staff change, in a second environment, for a test bench. Console state cannot, even when it is exportable.

Evidence accrues rather than being assembled

What matters is not the file but the interface behind it. When every function is reachable through a documented API, and the console is itself a client of that API rather than a privileged path around it, configuration, policy and compliance state become machine readable and machine writable.

That is the difference between passing an audit and preparing for one for six weeks. The report is generated rather than written, and it is current at the time of the audit rather than at the time of the last manual collection.

Git, YAML and SQL are hireable

An administration running an Apple fleet through a repository and a pipeline needs skills its IT department already has or can hire at market rate. A proprietary suite requires product-specific specialists who are scarce and expensive. Where staffing rather than licence budget is the binding constraint, this is a budget question rather than a matter of taste.

What this requires of the management plane

• A complete API that reaches everything the console reaches.
• Declarative target states rather than imperative command sequences, so the file describes the state and not the route to it.
• Artefacts that version sensibly: readable in a diff, stable in ordering, free of generated identifiers that change on every export.
• Machine-readable compliance state, retrievable without a click path.
• Self-hosted operation without loss of function where the environment requires it.

Those five are the test. A tool that offers an API while keeping the console as the real path does not pass it: whatever is possible by clicking and impossible by API will sooner or later be done by clicking.

Where the limits are

Not every setting is expressible declaratively. Apple's declarative device management covers a growing but incomplete share; the rest stays commands and scripts. User interaction cannot be declared away either: consent, recovery keys and first sign-in remain events with people in them.

Organisationally: whoever controls the pipeline controls the fleet. Repository and pipeline permissions become security-relevant and have to be governed accordingly. A repository also does not replace an ownership model, it makes the absence of one visible. And exceptions still need a procedure; the difference is that they show up as a deviation in a diff rather than as a silent special case on a device.

Where this ships today

Fleet Device Management currently implements this most consistently: device configuration as versioned files with a GitOps workflow, an API the console itself runs on, device state queried through SQL, open source, and self-hosted operation without loss of function up to air-gapped deployment.

Established management planes such as Jamf Pro, Omnissa Workspace ONE and Microsoft Intune offer APIs that allow parts of this to be rebuilt, and there are tools that layer configuration as code on top. The difference is whether the approach is the default or a discipline that has to be sustained against the tool. In regulated environments that decides the evidence question, because a discipline gives way under time pressure and a default does not.

Classified environments add a second condition: the management plane has to be MDM-TS certified and operated sovereignly. How the two connect is covered on the indigo page.