02 · Under-the-Hood Infrastructure as Code (IaC)

Milestones of the roadmap items in this theme

As of 2026-10-22 · today

Gantt

Milestones

#	Milestone	Start	Target	Status	Waits for	Team	Epic	Derived
04 · Declarative Infrastructure Framework
4.1	Cloud resources under Terraform	2026-07-06	2026-10-30	in progress	—	SRE	—	—
4.2	VMs under Terraform — KVM and Harvester	—	2027-01-15	planned	4.1	SRE	—	waiting 4.1
4.3	Database infrastructure under Terraform	—	2027-02-26	planned	4.1	SRE	—	waiting 4.1
4.4	Configuration management under Ansible	2026-07-06	2026-11-20	in progress	4.1	SRE	—	waiting 4.1
05 · Bare-Metal Infrastructure as Code
5.1	Netbox as the hardware source of truth	2026-08-03	2026-10-23	in progress	—	Hardware Operations	—	—
5.2	Out-of-band power and boot control automated	—	2027-01-01	planned	5.1	SRE	—	waiting 5.1
5.3	Unattended OS provisioning over iPXE	—	2027-02-12	planned	4.1, 5.2	SRE	—	waiting 4.1, 5.2
5.4	Racked to cluster member with nobody logging in	—	2027-02-26	planned	5.3	SRE	—	waiting 5.3
06 · Database Infrastructure as Code (Database IaC & DBaaS)
6.1	OpenMetadata cataloguing the database estate	—	2026-12-18	planned	—	SRE	—	—
6.2	Schema migrations as code	—	2027-01-15	planned	—	SRE	—	—
6.3	Replication, backup and lifecycle under GitOps	—	2027-07-16	planned	4.3	SRE	—	waiting 4.3
6.4	A database requested and delivered without a ticket	—	2027-11-19	planned	6.1, 6.3	SRE	—	waiting 6.1, 6.3
07 · Network Infrastructure as Code
7.1	Netbox holds the network's intended state	—	2027-01-01	planned	5.1	Network	—	waiting 5.1
7.2	Configuration rendered from code and validated	—	2027-02-26	planned	7.1	Network	—	waiting 7.1
7.3	Git is the only way a device changes	—	2027-09-10	planned	7.2	Network	—	waiting 7.2
7.4	Default-deny segmentation, and network requests as self-service	—	2028-01-14	planned	7.3, 22.2	Network	—	waiting 7.3, 22.2

Details

4.1Cloud resources under Terraform2026-10-30in progress · 2/4

• Repository layout, remote state and locking agreedowner · Charles

  State is the framework's real interface — where it lives, who may write it and how a run is locked decides whether two people can work at once.
• Module and naming conventions written downowner · Charles
• Existing cloud accounts imported, not rebuiltowner · TBD

  terraform import over what is already running first — the code has to describe the estate before it is allowed to change it.
• Plan and apply run in CI, no local appliesowner · TBD

  A local apply leaves state nobody else can reproduce; CI is what makes the framework the single path rather than one option among several.

4.2VMs under Terraform — KVM and Harvester2027-01-15planned · 0/4

• Harvester provider wired up, VMs declared as codeowner · TBD
• KVM hosts brought under the same frameworkowner · TBD

  Covers the VMs that have not moved to Harvester yet (item 09), so they stop being hand-built while they wait for migration.
• VM images and templates versioned with the codeowner · TBD
• The line with item 05 recorded: physical below, VMs hereowner · TBD

  05 owns Netbox, out-of-band control and iPXE — the fleet a VM runs on. Layered, not split by machine type.

4.3Database infrastructure under Terraform2027-02-26planned · 0/3

• Instances, parameter groups and backup schedules declared as codeowner · TBD
• Existing databases imported into stateowner · TBD
• The line with item 06 recorded: infrastructure here, self-service thereowner · TBD

  Item 06 builds the Backstage request flow and schema migrations on top of what this milestone provisions; it does not re-provision.

4.4Configuration management under Ansible2026-11-20in progress · 0/4

• Existing playbooks inventoried and folded into one repositoryowner · Charles

  They already run. The work is not adopting Ansible, it is ending the several unrelated ways it is run today.
• Role and inventory conventions written downowner · TBD
• Inventory generated from Terraform state, not maintained by handowner · TBD

  The handoff between item 04's two halves — provisioning declares what exists and configuration reads it from there, instead of from a parallel list that drifts.
• Playbooks run from CI; a host is reproducible from code aloneowner · TBD

  The same rule as 4.1's "no local applies" — a hand-run playbook leaves a host nobody can rebuild.

5.1Netbox as the hardware source of truth2026-10-23in progress · 1/4

• Every rack, chassis and server recorded with serial, MAC, rack position and BMC addressowner · TBD
• Netbox becomes where a change is made, not a copy kept in stepowner · TBD

  An inventory updated after the fact is a second system to keep honest. The hardware team edits Netbox; everything else reads it.
• Automation reads Netbox through its API, with no spreadsheet in the pathowner · TBD
• Drift check: what Netbox says against what the BMCs reportowner · TBD

  An inventory nobody checks turns into fiction quietly. The check is what keeps it a source of truth rather than a claim.

5.2Out-of-band power and boot control automated2027-01-01planned · 0/4

• BMCs reachable only from the isolated management networkowner · TBD
• Power and boot order driven programmatically, not from a web consoleowner · TBD

  The BMC protocol — IPMI, Redfish or a vendor interface — is a driver choice that comes with the provisioning tool, so this milestone does not have to settle it first.
• BMC credentials issued per identity, no shared accountowner · TBD

  Vault becomes the issuer once item 12 has milestones; until then this is a stated target, not a dependency the chart can draw.
• Human access stays with hardware operations (1.3); automation gets its own identityowner · TBD

  1.3 protects the out-of-band boundary — automation arriving on that network must not become the way around it.

5.3Unattended OS provisioning over iPXE2027-02-12planned · 0/4

• iPXE boot chain served from the management networkowner · TBD
• Harvester node images built and versioned as artefactsowner · TBD
• Provisioning driven by the IaC pipeline rather than a consoleowner · TBD

  The state backend and CI path established in 4.1 are what make this reproducible instead of a script someone remembers to run.
• The line with 1.4 recordedowner · TBD

  1.4 moves ownership of OS images and PXE to SRE; 5.3 makes that provisioning unattended. Ownership and automation, not two claims on one piece of work.

5.4Racked to cluster member with nobody logging in2027-02-26planned · 0/3

• One new server taken from racked to cluster member with no interactive loginowner · TBD

  The card's closing promise, run once for real. Anything that still needs a hand is a gap, and the run is what finds it.
• The run recorded: elapsed time and any manual step that remainedowner · TBD
• Gaps closed, or written down as known exceptionsowner · TBD

6.1OpenMetadata cataloguing the database estate2026-12-18planned · 0/4

• OpenMetadata deployed, ingesting from every database instanceowner · TBD
• Every asset carries a named ownerowner · TBD

  A catalogue without owners is a list. The owner is what turns a question about a table into a person to ask.
• Schemas and lineage captured, refreshed on a scheduleowner · TBD

  Lineage recorded once decays quietly; the schedule is what keeps it describing today's estate rather than last quarter's.
• The line with Backstage recordedowner · TBD

  OpenMetadata answers "what exists and whose is it"; Backstage is where you ask for one. Two systems with one job each, not two claims on the same job.

6.2Schema migrations as code2027-01-15planned · 0/4

• Migrations versioned in the service's own repositoryowner · TBD
• One promotion path — dev, staging, production — with no hand-applied SQLowner · TBD

  A schema changed by hand in production is a database no rebuild can reproduce — the same rule item 02 applies to services.
• Every migration states its rollback, or is expand-onlyowner · TBD
• Migration state visible in the catalogueowner · TBD

6.3Replication, backup and lifecycle under GitOps2027-07-16planned · 0/4

• Replication topology declared, not configured by handowner · TBD
• Backup schedules and retention as codeowner · TBD
• Restore rehearsed, not assumedowner · TBD

  A backup nobody has restored is a hope with a cron entry.
• Instance lifecycle — create, resize, retire — driven from the repositoryowner · TBD

6.4A database requested and delivered without a ticket2027-11-19planned · 0/4

• A developer requests an instance through self-service and receives it provisionedowner · TBD
• Defaults, quotas and ownership metadata applied without being asked forowner · TBD
• The new instance appears in the catalogue automaticallyowner · TBD

  Provisioning that does not register the asset creates the next generation of orphans — the ones item 03 then has to hunt.
• One request run end to end and timedowner · TBD

7.1Netbox holds the network's intended state2027-01-01planned · 0/4

• VLANs, prefixes, interfaces and firewall objects recorded in Netboxowner · TBD
• Intended state, not a picture of what the devices happen to holdowner · TBD

  An inventory that mirrors the devices can only ever agree with them. Recording intent is what makes a difference between the two mean something.
• Existing device configuration imported once, then owned by Netboxowner · TBD
• Drift between Netbox and the devices reported, not silently reconciledowner · TBD

  Silently overwriting either side hides the disagreement that matters.

7.2Configuration rendered from code and validated2027-02-26planned · 0/3

• Device configuration rendered from Netbox plus policy in Gitowner · TBD
• Rendered output validated offline against vendor syntax and site rulesowner · TBD
• Every change produces a reviewable diff before anything is pushedowner · TBD

  This milestone deliberately stops short of writing to devices. A renderer trusted with switches on the day it is first built is how a network goes down.

7.3Git is the only way a device changes2027-09-10planned · 0/4

• Pipeline pushes the rendered configuration; no hand-typed changes on switches or firewallsowner · TBD
• Console and device-local accounts reduced to break-glassowner · TBD

  The rule only holds if the other path is closed. Leaving it open makes "no hand edits" a request rather than a property.
• Drift detected on a schedule and raised as a change, not fixed by handowner · TBD
• Rollback is a revert, and it has been rehearsedowner · TBD

7.4Default-deny segmentation, and network requests as self-service2028-01-14planned · 0/4

• Segmentation policy expressed as code and applied default-denyowner · TBD

  The policy itself is set under the zero-trust theme; this is where it lands on real devices.
• Exceptions are entries in Git with an owner and a reason, not permanent holesowner · TBD
• A developer's network request is a self-service action, not a ticketowner · TBD

  Served by the same backend, so a request and a hand-made change cannot diverge. Backstage carries the form — the template that fulfils a network request is 22.2, which this milestone now waits on.
• One request run end to endowner · TBD

Back to the Platform Roadmap overview · the direction behind these milestones is the Platform Roadmap.