Build Machine DevOps Automation
Budget: $1,500 – $3,000 USD
The client operates under a strict, document-governed engineering model in which no developer is authorised to write production code except against a signed “Build Authority Packet.” Before any product engineer can be onboarded, that packet-generation system — the “Build Machine” — must exist. This role, referred to in the programme's internal documents as “Engineer #1,” is responsible for standing up the Build Machine: a policy-gated, evidence-producing pipeline that ingests approved engineering specifications and turns them into signed, auditable units of developer work.
This is fundamentally a platform/DevOps automation role — primarily configuration and integration of proven open-source tools, with a smaller component of custom scripting. It is explicitly not a product feature development role.
Key Responsibilities
Provision the Build Machine repository structure, including GitHub organisation setup, private repositories, and branch protection rules.
Configure a self-hosted GitHub Actions runner on a Hetzner Ubuntu LTS host.
Build a Docker Compose service stack for the Build Machine (no Kubernetes — that is reserved for later, product-side work).
Implement ingestion of the MES Registry (the programme's machine-readable engineering specification, in YAML) as the primary data source for packet generation.
Assemble Build Authority Packets from eligible registry entries, each carrying the full required field set (scope, non-scope, acceptance tests, dependencies, fail-closed behaviour, and more).
Implement Open Policy Agent (OPA/Rego) policy gates that validate every packet before it can be released — fail-closed by design.
Implement packet signing and verification using Sigstore (Cosign/Rekor), producing an immutable, auditable signing record.
Automate creation of a GitHub Issue from each signed packet, and monitor associated pull requests against packet scope.
Emit evidence records at each pipeline stage (assembly, validation, signing, release, PR review, completion) to support programme audit requirements.
Provide a working dry-run/test mode so the pipeline can be demonstrated end-to-end before any production packet is released.
Document every infrastructure and permissions decision made during setup for review by the Founder & CTO.
Core stack for this role
Policy-as-code: Open Policy Agent (OPA) and Rego, for declarative, auditable validation rules
Pipeline orchestration: Dagger, for portable, containerised, code-defined pipelines
Supply-chain security: Sigstore (Cosign keyless signing, Rekor transparency log)
CI/CD: GitHub Actions, including self-hosted runner configuration and management
Containers: Docker and Docker Compose (production-grade service orchestration, health checks, reproducible startup)
Linux server administration: provisioning and hardening an Ubuntu LTS host (Hetzner or equivalent cloud/VPS provider)
Scripting/automation: Python (registry parsing, packet assembly, dependency graphing) — comfort with structured YAML/JSON processing is essential
Git/GitHub administration: organisation setup, branch protection, Issues/Projects, GHCR (GitHub Container Registry)
Helpful additional exposure
Zero-trust service identity concepts (SPIFFE/SPIRE, mTLS) — relevant to later phases of the programme
Secrets/key management tooling (e.g. OpenBao/Vault-family products)
Software Bill of Materials (SBOM) and open-source licence scanning (e.g. syft, ort)
Working with LLM-assisted code review workflows (the pipeline integrates Claude for PR review)
Working style requirements
Comfortable operating inside a highly formal, document-driven engineering process with a single technical approval authority.
Able to work independently against a written specification and explicitly escalate rather than infer when something is unclear.
Rigorous about documentation — every infrastructure and permissions decision must be recorded for review.
All timestamps and logs must be recorded in ISO 8601 UTC format, regardless of the contractor's local timezone.
Definition of Done
GitHub organisation and repository structure live, with branch protection configured.
Build Machine host provisioned and documented; self-hosted runner installed, registered, and operational.
Docker Compose stack starts all Build Machine services reproducibly from a single command.
Registry ingestion works correctly — draft entries ignored, approved/build-ready entries processed.
Build Authority Packets can be assembled with all required fields populated.
Policy gates correctly reject invalid packets and pass valid ones.
Packets can be signed and independently verified.
A signed packet automatically creates a GitHub Issue containing the full packet content.
End-to-end evidence trail is produced for a complete test run, and a full dry-run demonstration completes without requiring any product code.
All infrastructure and permissions decisions are documented and handed over for review.
Engagement Length
~4.5 weeks (3 sprints: Sprint 0/1 – 2 weeks, Sprint 2 – 2 weeks, Sprint 3 – 1 week completion/handover)
Commitment
40 hours/week
This is fundamentally a platform/DevOps automation role — primarily configuration and integration of proven open-source tools, with a smaller component of custom scripting. It is explicitly not a product feature development role.
Key Responsibilities
Provision the Build Machine repository structure, including GitHub organisation setup, private repositories, and branch protection rules.
Configure a self-hosted GitHub Actions runner on a Hetzner Ubuntu LTS host.
Build a Docker Compose service stack for the Build Machine (no Kubernetes — that is reserved for later, product-side work).
Implement ingestion of the MES Registry (the programme's machine-readable engineering specification, in YAML) as the primary data source for packet generation.
Assemble Build Authority Packets from eligible registry entries, each carrying the full required field set (scope, non-scope, acceptance tests, dependencies, fail-closed behaviour, and more).
Implement Open Policy Agent (OPA/Rego) policy gates that validate every packet before it can be released — fail-closed by design.
Implement packet signing and verification using Sigstore (Cosign/Rekor), producing an immutable, auditable signing record.
Automate creation of a GitHub Issue from each signed packet, and monitor associated pull requests against packet scope.
Emit evidence records at each pipeline stage (assembly, validation, signing, release, PR review, completion) to support programme audit requirements.
Provide a working dry-run/test mode so the pipeline can be demonstrated end-to-end before any production packet is released.
Document every infrastructure and permissions decision made during setup for review by the Founder & CTO.
Core stack for this role
Policy-as-code: Open Policy Agent (OPA) and Rego, for declarative, auditable validation rules
Pipeline orchestration: Dagger, for portable, containerised, code-defined pipelines
Supply-chain security: Sigstore (Cosign keyless signing, Rekor transparency log)
CI/CD: GitHub Actions, including self-hosted runner configuration and management
Containers: Docker and Docker Compose (production-grade service orchestration, health checks, reproducible startup)
Linux server administration: provisioning and hardening an Ubuntu LTS host (Hetzner or equivalent cloud/VPS provider)
Scripting/automation: Python (registry parsing, packet assembly, dependency graphing) — comfort with structured YAML/JSON processing is essential
Git/GitHub administration: organisation setup, branch protection, Issues/Projects, GHCR (GitHub Container Registry)
Helpful additional exposure
Zero-trust service identity concepts (SPIFFE/SPIRE, mTLS) — relevant to later phases of the programme
Secrets/key management tooling (e.g. OpenBao/Vault-family products)
Software Bill of Materials (SBOM) and open-source licence scanning (e.g. syft, ort)
Working with LLM-assisted code review workflows (the pipeline integrates Claude for PR review)
Working style requirements
Comfortable operating inside a highly formal, document-driven engineering process with a single technical approval authority.
Able to work independently against a written specification and explicitly escalate rather than infer when something is unclear.
Rigorous about documentation — every infrastructure and permissions decision must be recorded for review.
All timestamps and logs must be recorded in ISO 8601 UTC format, regardless of the contractor's local timezone.
Definition of Done
GitHub organisation and repository structure live, with branch protection configured.
Build Machine host provisioned and documented; self-hosted runner installed, registered, and operational.
Docker Compose stack starts all Build Machine services reproducibly from a single command.
Registry ingestion works correctly — draft entries ignored, approved/build-ready entries processed.
Build Authority Packets can be assembled with all required fields populated.
Policy gates correctly reject invalid packets and pass valid ones.
Packets can be signed and independently verified.
A signed packet automatically creates a GitHub Issue containing the full packet content.
End-to-end evidence trail is produced for a complete test run, and a full dry-run demonstration completes without requiring any product code.
All infrastructure and permissions decisions are documented and handed over for review.
Engagement Length
~4.5 weeks (3 sprints: Sprint 0/1 – 2 weeks, Sprint 2 – 2 weeks, Sprint 3 – 1 week completion/handover)
Commitment
40 hours/week