--- title: "Architecture" canonical: "https://admiral.io/docs/architecture" description: "How Admiral runs: a managed control plane computes desired state and hands out work; agents in your clusters and clouds pull it over outbound connections." --- # Architecture Admiral is a hosted product. The control plane is managed by Admiral and runs at `api.admiral.io`; you never install or operate a server. What runs in your world is an **agent** inside each target you want to deploy to. This page covers that split. For the resource model (Sources, Components, Changesets, and so on) start with the [Concepts overview](https://admiral.io/docs/concepts.md). ## The shape [#the-shape] Control flows one direction: agents dial out to Admiral and pull their work. Admiral never reaches into your accounts or clusters, and holds no standing credentials to them. ## Admiral Cloud (the control plane) [#admiral-cloud-the-control-plane] The control plane is the always-on coordination layer that Admiral operates for you. It owns no execution; it computes desired state, hands out work, and records history. It is reachable two ways: * the **web** for interactive use, and * the **API** at `api.admiral.io` for the CLI, Terraform provider, Go SDK, and your own automation. All platform state - applications, environments, components, changesets, runs, revisions, agents, sources, and credentials - lives in Admiral Cloud. You do not provision a database or object storage; that is part of the managed service. ## Your execution fleet (agents) [#your-execution-fleet-agents] Agents are where deployments actually run, inside targets you own. An agent registers with Admiral, runs next to your workloads, and **pulls** its own work. There are two kinds: * **Terraform agents** execute `infrastructure` components (Terraform) wherever they have cloud access. They pull plan and apply jobs. * **Kubernetes agents** execute `workload` components (Helm, Kustomize, raw manifests) from inside the Kubernetes cluster they manage, GitOps-style. They pull rendered revisions and reconcile them. Both are kinds of the one Agent concept. See [Agents & Execution](https://admiral.io/docs/concepts/agents-and-execution.md). > **Note:** Agents are **outbound-only**. An agent dials `api.admiral.io` and needs no inbound path, no port mapping, and no route back from Admiral. This is why an agent in a local [kind](https://kind.sigs.k8s.io/) cluster works fine for evaluation: it just needs outbound internet. ## Interfaces [#interfaces] Everything available in the web UI is available programmatically: * **CLI** - `admiral` for day-to-day operation and CI. * **Terraform Provider** - manage Admiral resources declaratively. * **Go SDK** - build automation against the API. * **OpenAPI** - the REST contract behind the [API reference](https://admiral.io/docs/api.md). ## Why it is shaped this way [#why-it-is-shaped-this-way] * **Hosted control plane** means no server to install, scale, patch, or back up. You start from a signup, not an installation. * **Pull-based execution** means Admiral coordinates many clouds and clusters without ever being a point of inbound access to any of them. * **Self-contained desired state** (copy, not link) means an environment is answerable from its own data, and editing a shared template never changes a placed component silently. ## Where to go next [#where-to-go-next] - [Get Started](https://admiral.io/docs/get-started/overview.md): Connect a cluster and run your first deploy - [Concepts Overview](https://admiral.io/docs/concepts.md): The resource model the control plane operates on - [Agents & Execution](https://admiral.io/docs/concepts/agents-and-execution.md): The pull-based execution fleet in depth