Deployment Overview

Octo's platform runs on Kubernetes: the editor UI, the orchestrator, the observability service, Postgres, and NATS, with integrations deployed as pods at runtime. There are three ways to get that stack running, from a laptop to a public deployment.

You do not need a cluster. To try Octo, run the standalone editor from a single public image: see Running from Docker. To ship a single integration, bake its YAML into an image built on the public runtime and deploy it to Cloud Run or any container platform, as in Self-hosted integrations. The rest of this section is about deploying the full platform.

Ship one integration, without the platform

The platform earns its keep when you are running many integrations and want an editor, deployment history, and log aggregation behind them. A single integration needs none of that: it is YAML plus resources, and the public runtime image runs a directory of exactly that.

That image runs standalone, so its queues, KV store and leader election are in-process and last as long as the container. When you want them to survive a scale to zero, or to live in systems you already run, the octo-api build delegates every one of them to an HTTP server you implement.

Self-Hosted Integrations

Bake flows and resources into an image on the public runtime, and run it on Cloud Run or any container platform.

The Platform API

Give the runtime a platform of your own: object store, secrets, queues, leases and leader election behind one HTTP contract.

Choose a deployment path

Every path installs the same Helm chart. What differs is which values profile it uses and who runs the install.

	Local cluster (k3d / kind)	Helm chart	GCP reference (Terraform)
Best for	Development and evaluation	Any existing Kubernetes cluster	A public, TLS-terminated deployment you do not want to assemble
What you get	The full stack on `localhost`, with an optional hot-reload dev loop	The full stack, configured through chart values	Single-VM k3s with Traefik, Let's Encrypt TLS, per-integration subdomains, and Cloud Build releases
Images come from	Built locally and imported into the cluster	Public Docker Hub by default, or your own registry	Artifact Registry, pinned by digest by Cloud Build
Ingress / TLS	None (`localhost` port mappings)	Whatever the cluster provides; five TLS modes	Traefik + cert-manager, wired by Terraform
Prerequisites	`docker`, `k3d`, `devspace`, `task`	`helm` and a cluster	`gcloud`, `terraform`, `helm`, `docker`, `task`, a Cloud DNS zone
Bring it up	`task cluster:deploy`	`helm install oci://…`	`task infra:apply`, then `task deploy TAG=…`

No cluster, but you want a managed one? The middle column assumes you already have a Kubernetes cluster. If you do not, the repo also ships Terraform roots that create one (GKE Standard, GKE Autopilot or EKS), install its prerequisites, wire DNS and TLS, and deploy the chart in a single apply. See GKE and EKS.

They are a good way to see the whole thing working end to end, but they are not production infrastructure: their defaults are cheap and disposable on purpose, and each root deploys the application as well as the cluster. For a deployment you intend to keep, run the chart from your own values file against infrastructure you control, which is the interface these roots demonstrate.

The chart is published on every release, so the middle column needs no checkout:

helm install octo oci://ghcr.io/juancavallotti/charts/octo \--version 0.11.7 -n octo --create-namespace \--set ingress.host=octo.example.com

It ships a values profile per target (k3d, kind, GKE Autopilot, GKE Standard and EKS), so the differences between clusters (ingress class, TLS source, storage class, resource requests, security context) are configuration rather than forks. That one-liner is not an install to keep, though: it puts credentials in Helm values, where the release history keeps them. Follow Install on Kubernetes for the whole path, read Helm Chart for the reference, and see GKE or EKS for the managed-cluster specifics.

All paths deploy the same components: the platform (editor UI), the orchestrator, the observability service, Postgres, NATS, and a schema job that applies sql/schema.sql. The orchestrator then creates per-integration workloads at runtime when you deploy an integration from the editor. See Architecture and Deployments for how the pieces fit together.