# myriarch > Myriarch is an open-source OpAMP server and fleet manager for OpenTelemetry Collectors. Git is the source of truth for blueprints, fleets, rollout policies and the allowed collector versions; the web UI and the REST API operate within that frame, and every operator action is audited. What it does: collectors keep running under the upstream OpAMP Supervisor. The server myriarchd renders one configuration per collector from layered blueprints, offers it over OpAMP, rolls changes out in waves with approvals, health gates and rollback, and starts collector version updates through exchangeable executors, because the Supervisor cannot replace the collector binary. Who it is for: operators who run many OpenTelemetry Collectors on Linux and Windows hosts, in containers and on Kubernetes, at edge sites, in data centers and in the cloud. It is designed for around 1,000 collectors, with headroom up to 5,000 (design targets, not measured limits). License: the code is licensed under Apache-2.0 and the documentation under CC BY 4.0. Independence: myriarch is an independent project. OpenTelemetry, Kubernetes and CNCF are trademarks of The Linux Foundation, and myriarch is not affiliated with or endorsed by The Linux Foundation or the OpenTelemetry project. The names are used only to describe compatibility. Key terms: - **OpAMP**: The Open Agent Management Protocol of the OpenTelemetry project, a network protocol with which a server manages a fleet of telemetry agents: status reporting, remote configuration and package offers. - **OpAMP Supervisor**: The upstream process that starts and monitors a collector and speaks OpAMP for it. It manages configuration, health and restarts, but it cannot replace the collector binary. - **GitOps frame**: What a Git repository declares: blueprints, fleets, rollout policies and the allowed collector versions. The web UI chooses inside this frame, for example a target version from the allowed range, and never edits the declared state. - **Blueprint**: A layered, parameterized collector configuration. The server renders it into one content-addressed configuration per agent. - **Fleet**: A group of agents selected by their attributes. It decides which blueprint, which parameter values and which collector version the agents get, and which rollout policies apply. - **Rollout**: A controlled change of the configuration or the collector version of a fleet: in waves, with approvals, health gates, failure thresholds, pause, abort and rollback. - **Executor**: The way a collector version update is started: the host agent myriarch-updater, a webhook, an AWX job, or by hand. The server learns the result from the version that the collector itself reports. - **Programs**: myriarchd is the server (OpAMP endpoint, REST API, web UI, GitOps syncer and rollout engine). myrctl validates and renders a GitOps repository. myriarch-updater is the host agent for collector binary updates. myriarch-sim is the load simulator. ## Start here - [Getting started](https://myriarch.dev/docs/getting-started/): Tutorials that start a complete system on your own machine, from source, with Docker Compose or on a local kind cluster; the first two run the server in development mode, and none of them is a production setup. - [Local development](https://myriarch.dev/docs/getting-started/local-dev/): Build from source and run the server in development mode with an embedded database, the example GitOps repository and simulated collectors. - [Your first fleet and rollout](https://myriarch.dev/docs/getting-started/first-fleet-and-rollout/): Write a fleet and a rollout policy, enroll simulated collectors and roll out a change in waves, from source on a server in development mode. - [Docker Compose](https://myriarch.dev/docs/getting-started/docker-compose/): Evaluate the system on one machine from the release images, with the server in development mode (well-known logins, no TLS), PostgreSQL and simulated collectors; not a production setup. - [Kubernetes on kind](https://myriarch.dev/docs/getting-started/kubernetes-kind/): Run the server and collectors from the Helm charts on a local kind cluster, with a throw-away database and Git server; a demo setup, not a production setup. ## Facts and comparison - [Facts about myriarch](https://myriarch.dev/project/what-is-myriarch/): What myriarch is and is not: scope, license, size, maturity and version, in one page. - [Supervisor, own server or myriarch compared](https://myriarch.dev/project/comparison/): The OpAMP Supervisor alone, a server of your own on opamp-go and myriarch, with sources and dates, and when myriarch is not the right choice. - [FAQ](https://myriarch.dev/project/faq/): Short answers about OpAMP and the Supervisor, managing many collectors, version updates, updates without internet access, rollback, the OpenTelemetry Operator and the license. ## Concepts - [OpAMP, the Supervisor and the Collector](https://myriarch.dev/docs/concepts/opamp/): What OpAMP is, the parts of an OpAMP setup, how remote configuration reaches a collector and what the Supervisor cannot do, with dated sources. - [Git as the source of truth](https://myriarch.dev/docs/concepts/gitops/): How a Git repository describes blueprints, fleets, policies and executors, and how the server applies it. - [Agents](https://myriarch.dev/docs/concepts/agents/): Collectors and updaters as the server sees them, and how an agent is identified. - [Inventory](https://myriarch.dev/docs/concepts/inventory/): Server-side labels and parameter overrides for agents that match exact attribute values. - [Blueprints](https://myriarch.dev/docs/concepts/blueprints/): Layered collector configurations and how the server renders them. - [Fleets](https://myriarch.dev/docs/concepts/fleets/): How fleets select agents and how the target collector version is chosen. - [Rollouts](https://myriarch.dev/docs/concepts/rollouts/): Rollout policies, waves, approvals, maintenance windows and failure handling. - [Executors](https://myriarch.dev/docs/concepts/executors/): How collector version updates are started, with the updater, a webhook or AWX. - [Architecture](https://myriarch.dev/docs/architecture/): Components, data flows, high availability, scaling and observability. ## How-to guides - [Manage many OpenTelemetry Collectors with OpAMP and Git](https://myriarch.dev/docs/tasks/manage-many-collectors/): Set up the server, a GitOps repository, the hosts and the first rollout; the server in the tutorials runs in development mode. - [Upgrade the OpenTelemetry Collector on many hosts](https://myriarch.dev/docs/tasks/upgrade-collectors-on-many-hosts/): Set the target collector version in Git and roll it out with an executor, because the OpAMP Supervisor cannot replace the collector binary. - [Connect a host](https://myriarch.dev/docs/tasks/connect-a-host/): Enroll a Linux or Windows host with one command from the server, or with the installation scripts. - [Roll out a collector version](https://myriarch.dev/docs/tasks/roll-out-a-collector-version/): Update the collector version of a fleet and choose the version in the web UI within the frame that Git sets. - [Roll out a configuration change](https://myriarch.dev/docs/tasks/roll-out-a-config-change/): Change a blueprint in Git and watch the rollout engine apply it in waves. - [Validate a GitOps repository](https://myriarch.dev/docs/tasks/validate-a-gitops-repository/): Check a GitOps repository and render collector configurations with myrctl, locally and in CI. - [Track releases and send notifications](https://myriarch.dev/docs/tasks/track-releases-and-notify/): Follow upstream collector releases, review breaking changes before raising a target version, and route events to Teams, Slack or a webhook. - [Connect a real supervisor](https://myriarch.dev/docs/tasks/connect-a-real-supervisor/): Run the upstream OpAMP Supervisor and otelcol-contrib against a local server in development mode and watch the whole chain work. ## Reference - [GitOps schema reference](https://myriarch.dev/docs/reference/gitops-schema/): Every field of every GitOps object kind, with type and default. - [REST API](https://myriarch.dev/docs/reference/api/): The OpenAPI contract of the management API: authentication, roles, error format and every operation with its permission. - [CLI reference](https://myriarch.dev/docs/reference/cli/): The command-line tools myriarchd, myrctl, myriarch-updater and myriarch-sim. - [Server configuration](https://myriarch.dev/docs/reference/configuration/): Every key of the server configuration file, with type, default and effect. - [Metrics](https://myriarch.dev/docs/reference/metrics/): The Prometheus metrics of the server and the simulator, with type, labels and help text. - [Helm chart and values](https://myriarch.dev/docs/reference/helm-chart/): Installation, profiles, network policy, storage and the configuration values of the server Helm chart. - [Collector Helm chart and values](https://myriarch.dev/docs/reference/helm-chart-collector/): Modes, Pod Security, OpenShift, container mode and the configuration values of the collector Helm chart. ## Operations and security - [Install with Helm](https://myriarch.dev/docs/operations/install-helm/): Install the server on Kubernetes with the Helm chart. - [Install the collector with Helm](https://myriarch.dev/docs/operations/install-collector-helm/): Run collectors that myriarch manages on Kubernetes with the collector Helm chart and unchanged upstream images. - [High availability](https://myriarch.dev/docs/operations/high-availability/): How long a failover of the leader takes and the setting that bounds it. - [Support levels and tested platforms](https://myriarch.dev/docs/operations/tested-platforms/): The support level of every component and the platforms of the automated tests. - [Upgrade from v0.1.0 to v0.2.0](https://myriarch.dev/docs/operations/upgrade-to-v0-2-0/): What to do before and after the upgrade from v0.1.0 to v0.2.0. - [Production checklist](https://myriarch.dev/docs/operations/production-checklist/): The settings that matter for security and what the server refuses at startup. - [Troubleshooting](https://myriarch.dev/docs/operations/troubleshooting/): Symptoms, causes and fixes for the local system and for installations, and the endpoints that help to diagnose them. - [Authentication](https://myriarch.dev/docs/operations/authentication/): How people and agents authenticate: OpenID Connect, the bootstrap admin and enrollment tokens. - [Security model](https://myriarch.dev/docs/security/model/): Trust boundaries and security controls of the server, its agents and the updater. - [Verify releases](https://myriarch.dev/docs/security/verify-releases/): Check a release before you run it: checksums, keyless Sigstore signature and build provenance. ## Optional - [Roadmap](https://myriarch.dev/project/roadmap/): What the released versions contain, what comes next, what is intended for later and what is deliberately not planned. - [Release notes](https://myriarch.dev/project/changelog/): Notable changes of every release. - [Architecture decision records](https://myriarch.dev/docs/adr/): The decision records: why the system is built the way it is. - [Upstream notes](https://myriarch.dev/docs/design/upstream-notes/): Verified facts about the OpAMP Supervisor, the OpenTelemetry Operator and its OpAMP Bridge and other upstream software, each with a source and a date. - [Contributing](https://myriarch.dev/project/contributing/): Report a problem, propose a change, send a contribution. - [Source code](https://github.com/myriarch/myriarch): The repository with the code, the documentation sources and the issue tracker. - [Releases](https://github.com/myriarch/myriarch/releases): Release notes and signed release files.