Phase 9 shipped: Private Hetzner K3s

The first provider-backed template candidate adds private management, tunneled ingress, temporary administration, and pinned K3s bootstrap.

Phase 9’s implementation is live-certified. The template keeps provider and host semantics in native OpenTofu and Ansible, emits the standard non-secret inventory contract, and preserves ainfra’s reviewed lifecycle.

The cost-approved disposable deployment converged with zero change, completed Ansible check mode without drift, removed its temporary bastion without losing Cloudflare Service Auth SSH access, and retained a healthy three-server K3s control plane. Its exact destroy plan completed successfully, and independent Hetzner API queries confirmed that no Phase 9 resources remained.

Phase 8 shipped: Template authoring and conformance

ainfra now publishes a human and AI authoring contract, deterministic local diagnostics, and a provider-free clean-room proof.

Phase 8 makes the v1 template-authoring promise executable without requiring authors to inspect ainfra implementation source.

What shipped#

• Portable authoring diagnostics with typed failures and accurate inventory-free applicability.
• Complete human and self-contained AI authoring guidance.
• Standard native-variable documentation and live-evidence checklists.
• A provider-free clean-room template and complete local OpenTofu lifecycle.
• GitHub Pages documentation for authoring, validation, and security boundaries.

Read the complete Phase 8 development note or inspect v1.0.0-alpha.8.

Phase 7 shipped: Guarded MCP server mode

ainfra now exposes read-only inspection and explicitly authorized, plan-bound lifecycle operations through MCP over stdio.

Phase 7 exposed the existing typed application lifecycle through a guarded MCP adapter without weakening its authorization or evidence contracts.

What shipped#

• An official-SDK MCP server over newline-delimited JSON-RPC stdio.
• A fixed project boundary and read-only default tool registry.
• Sanitized doctor, status, output, inventory, schema, and documentation resources.
• Explicit planning and lifecycle capability allowlists.
• Independent authorization for deployment and destruction tools.
• The same locking, plan-binding, recovery, and evidence rules as the CLI.

Read the complete Phase 7 development note or inspect v1.0.0-alpha.7.

Phase 6 shipped: Destruction, recovery, and hardening

Reviewed destruction, interruption recovery, retained run browsing, redaction, and lifecycle security hardening are available.

Phase 6 closed the destructive lifecycle and retained-evidence boundaries.

What shipped#

• Exact reviewed destroy-plan execution and teardown evidence.
• Durable interruption diagnosis, status, and recovery guidance.
• Combined chronological retained-run browsing.
• Shared pre-sink redaction and deterministic private log rotation.
• Stronger binding, cache, permission, symlink, and hostile-input defenses.

Read the complete Phase 6 development note or inspect v1.0.0-alpha.6.

Phase 5 shipped: Output, inventory, and Ansible

Standardized non-secret output now drives deterministic inventory and controlled Ansible configuration with convergence evidence.

Phase 5 extended reviewed infrastructure application into deterministic host configuration.

What shipped#

• Strict validation of standardized, non-secret OpenTofu output.
• Pure and deterministic inventory generation.
• Controlled Ansible execution with native variable-file ordering.
• Durable bindings between configuration inputs and run evidence.
• Zero-change infrastructure and configuration convergence checks.

Read the complete Phase 5 development note or inspect v1.0.0-alpha.5.

Phase 4 shipped: Reviewed OpenTofu plans

OpenTofu changes can be planned, reviewed, bound to immutable inputs, and applied only from the exact saved plan.

Phase 4 delivered the first guarded infrastructure mutation workflow.

What shipped#

• Controlled OpenTofu initialization and planning.
• Sanitized structural summaries for human review.
• Immutable bindings across template, inputs, tools, and saved-plan bytes.
• Exact plan-ID application without implicit replanning.
• Durable evidence for started, terminal, cancelled, and ambiguous outcomes.

Read the complete Phase 4 development note or inspect v1.0.0-alpha.4.

Phase 3 shipped: Immutable template sources

Local and Git-subdirectory template sources can be locked, materialized, verified by digest, and checked for drift.

Phase 3 introduced the immutable template boundary consumed by every lifecycle operation.

What shipped#

• Local and Git-subdirectory source resolution.
• Canonical lock records with immutable revisions and tree digests.
• Contained, private template materialization and verified cache reuse.
• Explicit source updates with visible changes.
• Deterministic source, lock, digest, and cache drift diagnostics.

Read the complete Phase 3 development note or inspect v1.0.0-alpha.3.

Phase 2 shipped: Contracts and doctor

Deployment discovery, strict native-file contracts, deterministic doctor diagnostics, and approved local reconciliation are available.

Phase 2 made local deployments and templates discoverable, diagnosable, and safe to reconcile without contacting providers.

What shipped#

• Deterministic deployment discovery and target resolution.
• Strict parsing and validation of ainfra-owned contracts.
• Stable text and JSON doctor findings across supported scopes.
• Plan-before-write reconciliation for contained local artifacts.
• Negative tests for malformed, ambiguous, and unsafe inputs.

Read the complete Phase 2 development note or inspect v1.0.0-alpha.2.

Phase 1 shipped: Go project foundation

The compiled Go CLI, typed results, secure execution boundaries, and reproducible cross-platform build foundation are available.

Phase 1 established the Go implementation foundation used by every later ainfra lifecycle capability.

What shipped#

• A pinned Go module and functional ainfra command shell.
• Typed results with stable text and versioned JSON rendering.
• Secure filesystem and subprocess boundaries.
• Offline unit, component, adversarial, fuzz, and black-box tests.
• Reproducible Linux and macOS builds for amd64 and arm64.

Read the complete Phase 1 development note or inspect v1.0.0-alpha.1.

Phase 0 shipped: the ainfra v1 specification

The product contract for the ainfra v1 rewrite is accepted, integrated, and ready to guide implementation.

ainfra v1 has crossed its first roadmap boundary. Phase 0, Product specification, is shipped. The specification has been reviewed, accepted, and integrated into the v1 development line.

What Phase 0 established#

The specification defines the intended product before implementation begins. It covers:

• the v1 product boundary and lifecycle;
• native-file and template contracts;
• the security and secrets model;
• the Go architecture and source conventions;
• schemas, examples, and acceptance journeys;
• documentation and phase-note requirements; and
• the release-engineering process for the v1 line.

This gives implementation work a stable reference. Code, tests, templates, and user documentation can now be reviewed against the same contract instead of developing separate assumptions.

What shipped means#

shipped is the roadmap’s completed state. A shipped phase has an aligned specification, validation evidence, documentation, and development note.

Phase 0 delivered no runtime behavior. Its output is the normative contract that later phases implement. The detailed record is available in the Phase 0 development note.

Follow current progress on the ainfra roadmap. It is generated directly from the authoritative roadmap YAML.