macOS and Windows are the fastest ways to evaluate CuteOS locally. Existing Kubernetes is the operator-managed deployment option for teams already running a cluster.
Use the hosted installer for the fastest local setup. Switch to Existing Kubernetes when you want a direct Helm deployment into a cluster you already operate.
This is the recommended first install. It gets CuteOS running on Docker Desktop Kubernetes without requiring a source checkout.
Hosted installer entrypoint.
curl -fsSL https://install.cuteos.io/install.sh | bashRun these first if Docker Desktop, kubectl, or helm are missing.
brew install --cask docker
brew install kubectl helmUse the hosted PowerShell installer for the same local evaluation flow on Windows. Start from an elevated PowerShell session if Docker Desktop, WSL2, helm, or kubectl may need to be installed.
Hosted installer for Docker Desktop Kubernetes on Windows.
$tmp = Join-Path $env:TEMP 'cuteos-install.ps1'
Invoke-WebRequest https://install.cuteos.io/install-docker-desktop-k8s.ps1 -OutFile $tmp
powershell -NoProfile -ExecutionPolicy Bypass -File $tmpUse this when you already operate a cluster and want a direct Helm-based deployment with explicit release settings.
Pin an explicit tag outside throwaway local installs.
export RELEASE=cuteos
export NAMESPACE=cuteos
export FULLNAME="${FULLNAME:-$RELEASE}"
export TAG=latest
export ADMIN_PASSWORD='<set-a-strong-admin-password>'Minimal public chart path using the hosted chart asset and public registry.
helm upgrade --install "$RELEASE" https://install.cuteos.io/charts/cuteos.tgz \
--namespace "$NAMESPACE" --create-namespace --reset-values \
--set connector.enabled=false \
--set api.image.repository=registry.cuteos.io/cuteos/cuteos-control-plane \
--set api.image.tag="$TAG" \
--set executionRunner.image.repository=registry.cuteos.io/cuteos/cuteos-execution-runner \
--set executionRunner.image.tag="$TAG" \
--set executionRunner.env.CUTEOS_EXECUTION_RUNNER_MODE=kubernetes_job \
--set executionRunner.env.CUTEOS_EXECUTION_JOB_IMAGE="registry.cuteos.io/cuteos/cuteos-ansible-runner:${TAG}" \
--set nats.image.repository=registry.cuteos.io/cuteos/cuteos-nats \
--set nats.image.tag="$TAG" \
--set postgres.image.repository=registry.cuteos.io/cuteos/cuteos-postgres \
--set postgres.image.tag="$TAG" \
--set openbao.image.repository=registry.cuteos.io/cuteos/cuteos-openbao \
--set openbao.image.tag="$TAG" \
--set opa.image.repository=registry.cuteos.io/cuteos/cuteos-opa \
--set opa.image.tag="$TAG" \
--set minio.image.repository=registry.cuteos.io/cuteos/cuteos-minio \
--set minio.image.tag="$TAG" \
--set web.image.repository=registry.cuteos.io/cuteos/cuteos-web \
--set web.image.tag="$TAG"Runs the public bootstrap helper after Helm so the platform baseline is ready.
BOOTSTRAP_IMAGE="registry.cuteos.io/cuteos/cuteos-bootstrap:${TAG}" \
ADMIN_PASSWORD="$ADMIN_PASSWORD" \
RELEASE="$RELEASE" \
NAMESPACE="$NAMESPACE" \
FULLNAME="$FULLNAME" \
bash <(curl -fsSL https://install.cuteos.io/scripts/bootstrap-k8s.sh)The hosted installer pulls the current public assets, deploys the platform, and gets the local UI and API ready for use.
CuteOS fetches the current chart, Docker Desktop values profile, and bootstrap helper from install.cuteos.io.
The install paths use public images from registry.cuteos.io/cuteos and default to the latest tag unless you override it.
CuteOS installs into a Kubernetes namespace and reuses the Helm release path so existing installs are upgraded instead of being recreated from scratch.
After the chart is up, the bootstrap helper prepares the platform baseline and the local installers start API and web port-forwards by default.
These are the details that matter most during evaluation and when you rerun the installer later.
The hosted installer defaults to the cuteos release, the cuteos namespace, the latest tag, and the public registry at registry.cuteos.io/cuteos.
The public installer defaults to latest. Pin an explicit tag when you want reproducible operator-managed installs outside casual local testing.
The install paths are written around Helm upgrade behavior, so rerunning them updates the current release instead of creating a second copy.
The recommended local path assumes the docker-desktop Kubernetes context. Use the advanced Helm tab only when you intend to target a different cluster on purpose.
The local macOS and Windows installers start these port-forwards automatically unless you skip them. The commands below are useful for existing-cluster installs or when you want to run them manually.
Run in a separate shell if local port-forwards were skipped.
kubectl -n cuteos port-forward svc/cuteos-control-plane 18080:8080
kubectl -n cuteos port-forward svc/cuteos-web 18081:8080Sign in as admin with the password printed by the installer.
Most local install failures come from prerequisites, Docker Desktop Kubernetes state, or cluster context drift. Existing-cluster installs add the usual Helm and storage concerns.
The macOS installer requires kubectl and helm to be available before you start. Install them with Homebrew, then rerun the hosted installer.
Docker Desktop must have Kubernetes enabled before the local path can succeed. Confirm the docker-desktop context exists and kubectl cluster-info works.
The local installer warns if the current context is not docker-desktop. The advanced path should be run only when you intend to target an existing cluster.
Existing installs are upgraded in place. If the cluster already has a broken or heavily customized release, inspect Helm state and values before rerunning.
On arm64 Macs, local Docker pre-pull can be the first point of failure when an image is amd64-only. Rerun with bash -s -- --skip-prepull if needed.
The existing Kubernetes path expects a real cluster baseline for PostgreSQL, NATS, OpenBao, MinIO, and related persistent workloads.
CuteOS keeps the core install experience public and easy to use. The hosted installer, public chart, and public images are part of making the platform straightforward to evaluate and adopt.
Enterprise value belongs in the layers that add operational leverage: private catalogs, enterprise integrations, governance and compliance features, operational tooling, and commercial support.
Hosted installer, chart asset, public images, and community entry path.
Pack stores, enterprise catalogs, and organization-specific integrations.
Governance, compliance, support, and managed deployment layers.
A real community install path with enterprise layers where they help.
Use the public assets directly, or open the chart and quickstart docs when you need more environment-specific detail.
Infrastructure AI