OpenFrame CLI bootstraps k3d, GKE and EKS clusters for the OpenFrame platform

What openframe bootstrap is actually for

OpenFrame CLI, whose binary is called openframe, exists to solve one problem: getting a working cluster with the OpenFrame platform on top of it without hand-written scripts. The README describes OpenFrame as a unified, AI-driven MSP platform built by Flamingo, and the CLI as its primary bootstrap and lifecycle management tool. In practice that means six jobs in one binary: checking prerequisites, provisioning a cluster, installing the platform, monitoring status, upgrading it, and tearing it down.

The scope is narrower than it may first appear. The platform code itself lives in a separate repository, flamingo-stack/openframe-oss-tenant, and this CLI only deploys and manages it. The clusters it touches are local k3d clusters or cloud clusters on GKE and EKS, with Terraform doing the provisioning work underneath. Everything downstream of a successful bootstrap is ArgoCD: the platform is delivered as an app-of-apps, so the CLI is mostly an orchestrator in front of Helm, ArgoCD and a Kubernetes client rather than a platform runtime of its own.

The target user is an engineer on a team running managed service providers who wants the same environment on a laptop and in a pipeline. That framing matters, because the tool is opinionated about ArgoCD and about OpenFrame specifically.

Cluster, app and prerequisites are the three seams in the code

The architecture note describes the project as built around three core abstractions: cluster for provisioning, app for platform deployment through ArgoCD, and prerequisites for verifying and installing tools. The command tree under cmd/ follows that split, so the top level surface is bootstrap, cluster, app, prerequisites and update, and each of those groups has its own subcommands.

Underneath, the Go module is fairly conventional. Cobra drives command routing and flag parsing, pterm renders tables, spinners, boxes and coloured status output, and huh with bubbletea powers the interactive prompts and the k9s style status terminal. The Kubernetes side uses client-go directly, which the README says replaces shelled out kubectl calls. That matters for a bootstrap tool, because it means the CLI authenticates to the API server itself instead of parsing human readable command output.

The other half of the design is that many operations still call out to external binaries. Docker, k3d, Helm, Terraform, gcloud and the AWS CLI are invoked through a CommandExecutor abstraction, which is what makes those paths testable. k3d, Helm, mkcert, Terraform and infracost can be downloaded by a checksum verified layer with pinned versions.

Installing the binary without a package manager

There is no apt or brew install documented. On macOS and Linux the instruction is to take the platform appropriate archive from the Releases page, unzip it, and put the openframe binary somewhere on the PATH, for example /usr/local/bin. On Windows the README points at the AMD64 build directly, as a zip archive in the release assets, which you then unzip and run like any other binary.

If you already have a Go toolchain, the shorter route is a go install, which resolves the module path from go.mod:

go install github.com/flamingo-stack/openframe-cli@latest

Check the result with:

openframe --version

The build itself is reproducible by design. The Makefile sets the build flags as CGO_ENABLED=0 go build -trimpath, and the comment next to it explains that trimming paths is what matches the release build in .goreleaser.yml. A .goreleaser.yml and a .releaserc.yml are both present, so binary releases and the release notes appear to be produced by separate toolchains in the same repository.

A bootstrap is a k3d cluster plus an app-of-apps chart

The first run worth understanding is the local path. The documented sequence starts with a prerequisite check and then the bootstrap command:

# 1. Check that Docker/k3d/helm are ready (auto-installs on macOS/Linux where possible)
openframe prerequisites check

# 2. Bootstrap: creates a local k3d cluster AND installs the OpenFrame platform
openframe bootstrap

Step one detects missing tools, among them Docker, k3d, Helm, Terraform, gcloud and the AWS CLI, and can install some of them automatically on macOS and Linux. Step two is the interesting one. The description of the command gives the exact order: it validates or prompts for a cluster name, creates the k3d cluster, installs ArgoCD through Helm, installs the app-of-apps chart, waits until all ArgoCD applications report synced and healthy, and finishes by printing a summary card with access instructions.

That wait for healthy applications is the part that changes how this feels compared with a script. A script would exit as soon as the Helm command returned and leave you polling. Here the CLI blocks until the platform is actually up, and then tells you how to reach it:

openframe app status
openframe app access

For pipelines the same command runs without prompts:

openframe bootstrap --non-interactive

The README describes every workflow as having both an interactive wizard with prompts, spinners and cost estimates, and a non-interactive or skip-wizard path.

Twenty-four gigabytes of RAM is the real cost of the local path

This is where the tool stops being a casual convenience. The documented hardware requirements for a full local OpenFrame install are a minimum of 24 GB of RAM, 6 CPU cores and 50 GB of disk, with 32 GB, 12 cores and 100 GB recommended. The README is explicit that these figures reflect running the complete platform, ArgoCD plus the app-of-apps, inside k3d on your own machine. A developer laptop with 16 GB will not hold this comfortably, and there is no smaller profile documented to fall back on.

The cloud path does not avoid the requirement, it relocates it. GKE and EKS are provisioned through Terraform, so the compute cost moves to the provider, but the CLI host still has to run Docker, Terraform and Helm operations. A workstation with modest local resources can therefore drive a cloud cluster, as long as the provider account carries the quota and the credentials the wizard needs.

Two further limits deserve attention. First, the platform delivered is whatever the app-of-apps chart contains, so your real configuration surface is the Helm values rather than the CLI flags. The repository root carries helm-values.yaml and an openframe-helm-values.example.yaml, which suggests values files are the intended way to steer an install, though the README does not document a full values override workflow. Second, the CLI manages the platform through ArgoCD and does not touch the underlying cluster, so any change you make directly to deployed resources can drift from the chart, and the sync button in the status view is the piece that will undo it.

Pinned downloads and cosign for the self-update path

The CLI installs its own dependencies rather than trusting what is already on the machine. The README states that tool binaries are downloaded with pinned versions and SHA256 checksum verification, explicitly avoiding the curl piped into bash pattern, and that CLI self-updates are verified with Sigstore and cosign signatures. The go.mod file carries github.com/sigstore/sigstore-go v1.3.0 and github.com/hashicorp/terraform-exec v0.25.2, which lines up with that description of the toolchain.

The self-update command is separate from the platform upgrade path, and that is worth keeping straight. openframe update handles the CLI binary itself, and the feature list says it checks for, downloads, verifies and applies new CLI releases with rollback support. Upgrading the deployed OpenFrame platform is a different action, done through the app abstraction and therefore through ArgoCD.

There is a small but telling detail in go.mod. The module declares go 1.26.0 with toolchain go1.26.5, and a comment explains that earlier 1.26 point releases crash at random on windows-amd64 because of a garbage collection stack scanning bug, tracked upstream as golang/go#77975. The comment states that CI and releases resolve the toolchain from this file. The practical consequence is that a Windows user building from source needs the pinned toolchain rather than whatever Go version happens to be installed.

The licence is a custom Flamingo document, not an OSI identifier

The licence field on the repository says Other, with a note that GitHub cannot classify it and that the LICENSE file holds the terms. The README badge names it FLAMINGO AI Unified v1.0, which is consistent with a custom contract rather than an open source licence. Nothing here is legal advice, but the practical points for an engineer are plain. You cannot assume the usual MIT or Apache grant of use, modification and redistribution. The root of the repository also carries PAYMENT-TERMS.md, PRIVACY.md, TERMS.md, SECURITY.md, CONTRIBUTING.md and AGENTS.md, which suggests the CLI ships alongside commercial and policy documents for the platform rather than as a self contained utility.

That also shapes how the project should be evaluated. OpenFrame CLI is a component of a wider ecosystem whose main platform code sits in flamingo-stack/openframe-oss-tenant, and a team that only wants a cluster tool will find most of this surface irrelevant. A team that has already decided to run the OpenFrame platform gets a bootstrap that is tedious to build by hand.

Maintenance itself is current. The repository is not archived and the last push was on 2026-10-14. The recent release history moves quickly through a narrow window, with 0.6.0 on 2026-08-05, 0.7.0 on 2026-08-06 and 0.7.1 on 2026-08-07, so releases are frequent and the project is still moving.

Where the CLI is the wrong tool

Three cases stand out. If you are not running OpenFrame, the app-of-apps install and the ArgoCD coupling buy you nothing, and kubectl plus a Helm chart is the smaller dependency. If you are looking for general cluster lifecycle management, the cluster abstraction is scoped to k3d, GKE and EKS, and there is no documented support for other providers. If you work on a machine below the 24 GB floor, the local path is off the table even though the tool itself is small.

The comparison worth making is with the alternative of wiring the same steps yourself. A hand written shell script would need to call k3d, install ArgoCD with Helm, add the app-of-apps chart, then poll for healthy applications, which is exactly the wait the CLI absorbs. Against a generic cluster provisioner such as Terraform alone, the difference is that Terraform ends at the cluster boundary and leaves the platform install to you, while the CLI carries the platform layer. Against a Kubernetes operator, the difference is that an operator stays resident and reconciles continuously, whereas this CLI performs one-shot actions and delegates ongoing reconciliation to ArgoCD.

The gap between the two closest approaches is a day of scripting versus a day of learning the command surface and the values files. If your team scripts these steps once and moves on, the CLI may repay more than it costs.

Editorial conclusion

OpenFrame CLI is worth adopting for engineers who actually need the OpenFrame platform running on a Kubernetes cluster, because the k3d path plus app-of-apps install in a single command is genuinely hard to reproduce by hand. It is the wrong tool for general cluster administration, for platforms other than OpenFrame, or for teams unwilling to hold a custom licence and a 24 GB workstation. Before committing, check the exact Helm values you intend to apply, confirm your provider credentials and quotas cover the resources the wizard estimates, and read LICENSE.md together with PAYMENT-TERMS.md, since the licence field on the repository says Other rather than a standard OSI identifier.

Frequently asked questions

Official sources

1. flamingo-stack/openframe-cli on GitHub
2. Issues
3. README
4. Releases