Octov0.4.2
Deployment

Deployment Overview

Ways to deploy Octo: local k3d, Helm on any Kubernetes, or GCP with Terraform.

Octo's platform runs on Kubernetes: the editor UI, the orchestrator, the log aggregator, 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 — see 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.

Choose a deployment path

Local cluster (k3d)Helm chartGCP reference (Terraform)
Best forDevelopment and evaluationAny existing Kubernetes clusterA public, TLS-terminated deployment
What you getThe full stack on localhost, with an optional hot-reload dev loopThe full stack, configured through chart valuesSingle-VM k3s with Traefik, Let's Encrypt TLS, per-integration subdomains, and Cloud Build releases
Images come fromBuilt locally and imported into the clusterYour registry (published with task images:push)Artifact Registry, built by Cloud Build on version tags
Ingress / TLSNone — localhost port mappingsTraefik Ingress + cert-manager (configurable)Traefik + cert-manager, wired by Terraform
Prerequisitesdocker, k3d, devspace, taskhelm, a cluster, a registrygcloud, terraform, helm, docker, task, a Cloud DNS zone
Bring it uptask cluster:deployhelm install / helm upgradetask infra:apply, then task deploy TAG=…

All three paths deploy the same components: the platform (editor UI), the orchestrator, the log aggregator, 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.

Supporting references

On this page