Kubernetes operators
without the infrastructure

Reconciliation, security, and intent delivery — as runtime services.
You declare behavior; Orkestra runs it.
No boilerplate. No scaffolding. No ceremony.
Keep your existing Reconcile() — or point to an HTTP server in any language.

$ brew install orkspace/tap/ork
Reconciliation
as a runtime service

Informers, workqueues, workers, leader election, retries, finalizers, drift correction, status patching, panic recovery — provided unconditionally to every CRD in your Katalog. You own the declaration. Orkestra owns the loop.

Security
as a runtime service

Admission webhooks, validation rules, mutation rules, RBAC generation, TLS management, deletion protection, namespace isolation, pod security — derived from your declarations. The default posture is the safe one.

Intent Delivery
as a runtime service

CR construction, caller interfaces, field routing, value translation, schema evolution — any caller submits flat intent in their own vocabulary. The gateway translates, validates, stamps provenance, and delivers. No caller sees a CRD schema.

Quick Start

From CRD to running operator

Two binaries: ork is the operator CLI. orkcc is the Control Center.

OS
Method
ork init · ork run
zsh
Super-operator model

Your CRD doesn't get a shim. It gets everything.

Traditionally, your operator has whatever you built into it. If you forgot metrics, there are no metrics. In Orkestra, the runtime provides the full stack unconditionally to every CRD in your Katalog.

Infrastructure removed
hello-website/katalog.yaml Complete operator · No Go required
apiVersion: orkestra.orkspace.io/v1
kind: Katalog
metadata:
  name: hello-website

spec:
  crds:
    website:
      crdFile: my-website.yaml
      operatorBox:
        reconcile:
          onCreate:
            deployments:
              - image:    "{{ .spec.image }}"
                replicas: "{{ .spec.replicas }}"
                reconcile: true
Built-in observability

One dashboard for every Orkestra runtime

The moment you run ork run, a live dashboard starts on :8081 — showing every CRD, worker, queue depth, and reconcile event. No extra setup.

Multi-runtime aggregation
Monitor every Orkestra instance — across clusters, namespaces, or environments — from a single Control Center.
Per-CRD drill-down
Click any CRD to see worker pool depth, queue pressure, admission stats, and live CR instances.
Zero configuration
Built into the ork CLI. Launch with ork control — no additional binary or Helm chart.
Live Control Center ↗ Read the docs →
localhost:8081
platform-operator
infra-operator
database-operator
platform-operator ● Healthy
4CRDs
16Workers
247Resources
0Errors
database
● Healthy · 4 workers
Queue: 3/64 · Uptime: 48h
application
● Healthy · 4 workers
Queue: 2/64 · Uptime: 47h
cache
⚠ Pending · 0 workers
Waiting for: database
ingress
● Healthy · 4 workers
Queue: 1/64 · Uptime: 48h
Gateway & Serve layer

Any caller. Any vocabulary. One operator.

Add serve: true to a CRD entry. Your operator instantly surfaces a token-scoped API. Callers submit flat intent in their own vocabulary. Orkestra translates, validates, stamps provenance, and applies.

When the CRD schema changes — a field moves, a structure deepens — update one line in the serve declaration. Callers notice nothing.

CI pipeline (token)
Slack command
Browser form (Control Center)
GitHub webhook
curl / HTTP
PagerDuty / cron
intent → cluster
# What the caller submits (flat, no Kubernetes)
target:      app
name:        payments-api
repository:  myorg/payments-api
environment: staging
team:        payments
replicas:    2

# What Orkestra builds and applies
apiVersion: platform.myco.io/v1
kind:       App
metadata:
  name:      payments-api
  namespace: team-payments-staging
  annotations:
    orkestra.sh/target:  app
    orkestra.sh/source:  github-actions
    orkestra.sh/subject: repo:myorg/payments:ref:main
spec:
  source.repository: myorg/payments-api
  environment: staging
  replicas:    2
Pattern registry

Distribute behavior, not binaries

The Orkestra Registry distributes operator patterns as OCI artifacts. A Katalog pulled at postgres:v14 behaves identically in every environment. Uses your existing docker login. See production deployment →

Every pattern ships with a declarative E2E test that gates publication. You do not push a pattern without proof it works.

ork pull postgres:v14 ork push my-operator:v1 . ork patterns
Orkestra Core

Three independent components

No shared database. No shared cache. No direct in-process calls. Run them on the same pod or entirely separate deployments.

ork run

Runtime

The reconciliation engine. Watches Kubernetes resources, runs operator logic, manages resource lifecycle, exposes the /katalog API.

ork gate

Gateway

Serves admission and conversion webhooks, handles notifications, validates and delivers intent. Stateless, multi-replica. No reconciliation logic.

ork control

Control Center

Connects to one or more runtimes, reads their /katalog APIs, and renders a live view of every operator, CRD, worker, and CR in your fleet.

Community

Everyone welcome!

Open source. Apache 2.0. Built in the open.

Learn

From the blog

📄→

Your CRD Is Enough

Why reconciliation is a data problem, not a programming problem — and how the Katalog completes the promise Kubernetes made in 2017.

🎹→

Why I Built This

A missed interview, a wall of boilerplate, and a pattern that kept repeating. The story behind the super-operator model and the music metaphor.

🚀→

What If the Next Ops Is IntentOps?

DevOps. GitOps. PlatformOps. Every shift absorbed complexity from callers. IntentOps absorbs the manifest itself.

CLI & Ecosystem
ork run ork gate ork control ork validate ork simulate ork e2e ork proxy ork migrate ork patterns ork push ork pull ork token Remote Reconciler Reconciler Model Execution Model Operator of Operators Self-Service Lifecycle Reusability OperatorBox Profiles Kordinator Control Center Operator Autoscaler Workload Autoscaler External Protocols