Skip to content
For platform teams

You already operate a platform.
Here's how Theo fits.

If you're a Head of Platform Engineering, DevOps Director, or you operate an internal IDP (Backstage, Argo, Crossplane, custom), this page is for you. TheoCloud is not designed to replace your platform — it adds a workload runtime for the agent-shaped class (LLM-bound, long-running, sub-agent fan-out) that generic cloud platform underserves. Below: the six questions platform teams ask before adoption.

6 questions platform teams ask

Coexistence — not replacement

“Does TheoCloud replace my internal platform?”

No. Most adopters of Theo Enterprise self-host run Theo as ONE deploy target within their broader platform. Theo handles the agent-shaped workload class (LLM-bound, long-running, sub-agent fan-out) that generic cloud platform layers underserve. Your internal platform keeps owning what it owns — service mesh, secret broker, IDP portal, observability federation, custom buildpacks. Theo plugs in as a workload runtime, not as a competing control plane.

GitOps — your GitOps tool / Flux stays primary

“How does Theo fit my GitOps stack?”

Two patterns. (1) Theo-managed: theo deploy is the source-of-truth for the agent deploys; your GitOps tool watches separate config. (2) GitOps-managed (Enterprise): your GitOps tool drives Theo config (theo.yaml); the Theo control plane applies it. Pattern 2 ships Q3 2026 for Enterprise. Pattern 1 is shipped today.

Extensibility — OPA, buildpacks, templates

“Can I extend Theo with my own policies and templates?”

Templates: TheoKit templates are Apache-2.0; fork the repo, publish under your org namespace (template-my-org-fastify), reference from theo.yaml. OPA/Rego policy gates: roadmap Q3 2026 for Enterprise — admission hook before deploy. Custom buildpacks (your own RUN steps, sidecars, mesh injection): roadmap Q4 2026; today the standard builder covers Node/Go/Python/Rust/Java/Ruby/PHP/Next.js.

BYOC vs Self-managed — two operational modes

“When I "self-host Theo Enterprise", what do I actually run?”

Two named modes. (a) BYOC (Bring Your Own Cloud): the Theo control plane runs as Theo-managed SaaS; it provisions and operates workloads on your infrastructure across your AWS/GCP/Azure account. You own infra; we own the control plane. (b) Self-managed: you operate both the Theo control plane AND the data plane inside your infrastructure. Highest sovereignty; you own the operational footprint (dedicated compute for the HA control plane plus tenant workloads).

IDP integration — Backstage plugin

“Can I surface Theo inside my Backstage / internal portal?”

Backstage plugin: roadmap Q3 2026 (catalog entity + deploy actions + status widget). Today: REST API on the Theo control plane lets you build a custom Backstage card in ~1 day. API docs ship with the Enterprise architecture deck under NDA.

Observability federation — BYO Datadog / Splunk / Elastic

“Do I have to switch SIEM/APM to use Theo?”

No. Theo exports OpenTelemetry-formatted logs + metrics + traces. Native exporters to Datadog, Splunk HEC, Elastic Cloud, S3 (cold storage), Prometheus federation. Your platform keeps owning observability; Theo emits, you collect. See /observability for the full integration list.

Architecture deep-dive

5-step flow, tenant isolation (container isolation + project-level isolation + dedicated infrastructure), envelope encryption, network model.

Talk to platform engineering

Founders take platform-coexistence calls personally. Email [email protected] with your stack — GitOps tool, IDP, mesh, OPA — for a 30-min architectural review.

Architecture deck under NDA documents the integration patterns, GitOps managed pattern, OPA/Rego policy hooks, and Backstage plugin in detail — email [email protected].