Krops 0.2.0 uses existing Kubernetes APIs instead of a new controller
Krops 0.2.0 puts infrastructure desired state into Git as Kubernetes YAML, then lets Flux and controllers reconcile it continuously. Cluster API handles clusters, AWS Controllers for Kubernetes handles cloud resources, and Kubernetes supplies RBAC and audit records. Krops does not add its own custom resource or long-running controller. The only project-specific program is the krops-bootstrap CLI for initial bootstrap, control-plane pivot, and teardown. This is appealing when those upstream APIs already describe what a platform needs and another abstraction would only hide them.
The scope is still larger than the 203-file checkout suggests. Our scan counted roughly 9,360 lines of source in 3.7 MB, split across Rust, shell, Python checks, Flux manifests, Kustomize overlays, and documentation. The repository includes an AWS EKS environment, a local Docker environment, and a Talos-on-Tinkerbell environment. A Zarf path packages the local setup for disconnected operation. Krops calls itself a working reference implementation, so the expected adoption path is to fork it, remove irrelevant environments, and own the remaining manifests.
What happened when we ran it
Our sandbox installed 151 Rust packages in 28 seconds at commit 3927df5. The project lives under bootstrap-rs/, a detail that matters when running Cargo commands manually. Compilation succeeded in 75 seconds. The repository had 5 CI workflow files, a Dockerfile, and a tests directory. Compared with the other projects in this batch, the codebase gave the clearest fresh-container result: its documented Rust subproject resolved and built without a missing tool or hidden credential.
Cargo test completed in 44 seconds with 100 passed and 0 failed out of 100. The measurement covers the Rust project in our unprivileged 3-CPU, 12 GB sandbox. It does not prove that EKS, Flux reconciliation, Tinkerbell PXE, or air-gapped deployment works on your infrastructure. Those paths require container engines, clusters, networks, and external controllers that the Cargo suite cannot reproduce. Still, a fully passing local test result gives a much better starting point for changing lifecycle code than an untested collection of shell scripts.
Local evaluation needs an engine socket and creates two clusters
The local-host quick start requires Docker or Podman 5.5+, then builds bootstrap-rs/Dockerfile because no semver toolbox release exists. The container mounts the repository, a writable .kube directory, and the host engine socket. Krops creates a kind management cluster, a local registry, and a one-control-plane, one-worker workload cluster through Cluster API's Docker provider. A separate Flux instance runs on the workload cluster and deploys Podinfo, giving operators an end-to-end path that spends no AWS money.
Native setup adds Mise 2026.8.10 or newer and the Rust toolchain, while the toolbox carries kubectl, kind, Helm, Flux, clusterctl, SOPS, age, and AWS utilities. The 75-second Rust build is a small part of that toolchain. AWS needs a repository PAT, age keys, broad cluster-creation permissions, and capacity for at least 3 free Elastic IPs plus 4 vCPUs of the named GPU instance class. The operations guide documents credential forwarding and teardown switches carefully, but each permission and quota still belongs to the adopting operator.
AWS pivot and control-plane recovery remain unverified
Krops 0.2.0 had no GitHub release listed on September 9, 2026. The repository has a workflow configured to publish signed amd64 and arm64 toolbox images with an SPDX SBOM after a matching version tag, but the README describes that event in the future. Issue 143 says the AWS pivot has never run against real AWS, even though its repository work is merged. Local-host pivot evidence cannot establish that existing EKS workload clusters survive a management-control-plane move without disruption.
The hardware path also needs precise reading. A Talos acceptance run completed, but issue 225 says it used a hand-booted ISO instead of the documented PXE and Tinkerbell Workflow. The project still needs a real PXE run. High-priority issue 186 is designing disaster recovery for loss of the self-managed management cluster, including which runtime state and secrets Git cannot reconstruct. Those are adoption gates for a control plane that may manage surviving production clusters after its own failure.
The arm64 air-gap path has real evidence and known limits
The 3.7 MB checkout includes an arm64-only Zarf path that was deployed with Wi-Fi disabled on August 18, 2026. Its flow verifies package signatures and checksums before changing a cluster, includes Syft SBOMs, and checks that reconciled images come from the internal registry. The current package keeps kind as the management substrate, and the connected toolbox is not included in its inventory. This is unusually specific documentation for disconnected testing, while those stated limits keep the result tied to one architecture and one reference environment.
GitHub showed 132 stars, 33 open issues, 4 open pull requests, and a last push on September 9, 2026. Same-day issue and pull-request updates, plus a run of merged Renovate changes on September 8, show active maintenance. The open work is substantive: scheduled deployment testing, AWS proof, disaster recovery, and coherent air-gap dependency updates. Crossplane is the safer comparison for an established Kubernetes infrastructure platform. OpenTofu or Pulumi fits teams that prefer an external infrastructure engine. Krops fits teams prepared to own this exact GitOps pattern and its operational evidence.