--- title: Agent types source: https://docs.newrelic.com/docs/new-relic-control/agent-control/agent-types --- > #### ⚠️ IMPORTANT > > Agent Control and New Relic Control are **generally available** for Kubernetes. Support for Linux and Windows hosts is in **public preview** program, pursuant to our [pre-release policies](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy). An agent type definition is a YAML file that describes how Agent Control should identify, download, configure, and run a specific agent. Its declared variables also form the configuration schema that Fleet Control exposes to operators when deploying or updating a sub-agent from the fleet. Every definition consists of three main sections, **metadata**, **variables**, and **deployment**, plus a top-level `protocol_version` field that versions the schema language the file is written against. ## Metadata The metadata section identifies the agent type: its `name`, `namespace`, `version`, target `platform` (`host` or `kubernetes`), and `operating_system` (required for host-based types). Agent Control uses these fields to uniquely address the definition and dispatch it to the correct deployment engine. ## Variables The variables section declares the configurable inputs that operators can set when adding a sub-agent to their configuration. Each variable has a `type` (such as `string`, `bool`, or `yaml`), an optional `default`, and an optional `variants` list of accepted values. Variables are referenced throughout the deployment section using `${nr-var:variable_name}`. ## Deployment The deployment section describes how Agent Control installs and runs the agent on the target platform. It is composed of several sub-sections: - **`packages`**: OCI artifacts to download before the agent starts — typically the agent binary or integration package. - **`executables`**: the list of processes Agent Control will start, monitor, and restart. An agent type without this section is treated as a managed integration (OHI): Agent Control handles its artifacts but delegates execution to another agent. - **`health`**: how Agent Control determines whether the agent is healthy — via process presence, an HTTP endpoint check, or both. - **`filesystem`**: individual files or directories that Agent Control writes to the host before starting the agent, such as configuration files or certificates. - **`shared_filesystem`**: entries written into a shared drop zone accessible to other agents managed by the same Agent Control instance. Used by OHI agent types to hand their configuration and binaries to the Infrastructure Agent. For the full schema reference and all available fields, see [Agent type schema reference](https://github.com/newrelic/newrelic-agent-control/blob/main/docs/agent_type.md). ## Fetch agent type definitions Agent Control fetches agent type definitions from a remote OCI registry, identified by the `namespace`, `name`, and `version` declared in the definition's metadata section. By default, Agent Control pulls from `docker.io`, using the `newrelic/agent-control-agent-types` repository. Agent Control signature-verifies each definition against the New Relic public key before pulling it. You can mirror this registry the same way as agent packages. ## Linked agent types Two agent types are **linked** when one writes artifacts (configuration, binaries, or other files) into the shared filesystem and the other is configured to read from those same paths. The writer may have no `executables` section, Agent Control manages its artifacts but never starts a process for it. Instead, the reader agent has the built-in logic to discover and execute binaries and configurations from a well-known path in the shared filesystem, effectively running the add-on on the writer's behalf. The shared filesystem root is: | OS | Path | | ------- | ------------------------------------------------------------------- | | Linux | `/var/lib/newrelic-agent-control/shared-filesystem` | | Windows | `C:\ProgramData\New Relic\newrelic-agent-control\shared-filesystem` | All agents managed by the same Agent Control instance share this root. Subdirectory names are chosen by convention between the linked agent types. ### On Host Integrations (OHI) On-Host Integrations (OHIs) are the primary example of linked agents in Agent Control; where other agents have a process started by Agent Control, OHI agents have no process of their own and Agent Control never starts them. They let Agent Control manage the full lifecycle of New Relic infrastructure integrations, downloading, configuring, upgrading, and uninstalling them while delegating their execution to the Infrastructure Agent, which discovers and runs the integration binaries from the shared filesystem. ### The Infrastructure Agent and OHI agent relationship 1. When an OHI agent type is installed, Agent Control downloads the integration binary via OCI and writes two entries into the shared filesystem: - A config file under `infra-agent-ohi-configs/` (e.g. `nri-redis.yaml`) - The integration binary under `infra-agent-ohi-binaries/` (e.g. `nri-redis`) 2. The Infrastructure Agent sub-agent is configured with environment variables that point it at these shared directories: | Variable | Shared filesystem path | Purpose | | ------------------------------------- | ---------------------------- | ----------------------------- | | `NRIA_PLUGIN_DIR` | `…/infra-agent-ohi-configs` | Integration config discovery | | `NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR` | `…/infra-agent-ohi-binaries` | Integration binary discovery | | `NRIA_SAFE_BIN_DIR` | `…/infra-agent-ohi-binaries` | Allowed binary execution path | 3. The Infrastructure Agent picks up the config and binary on its next scan cycle and begins running the integration. ``` shared-filesystem/ ├── infra-agent-ohi-configs/ # Integration YAML configs (read by NRIA_PLUGIN_DIR) │ ├── nri-redis.yaml │ └── nri-mysql.yaml └── infra-agent-ohi-binaries/ # Integration binaries (read by NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR) ├── nri-redis └── nri-mysql ``` > #### ⚠️ IMPORTANT > > OHI agent types have no process of their own and depend entirely on the Infrastructure Agent to > execute. You must have `com.newrelic.infrastructure` configured as a sub-agent in the same Agent > Control instance before deploying any OHI agent type. ## Supported agent types ### Current support The following table shows which agent types Agent Control supports and their availability across environments. | Agent type | Kubernetes support | Linux host support | Windows host support | | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------------------ | -------------------- | | [**New Relic infrastructure agent**](https://docs.newrelic.com/docs/infrastructure/infrastructure-agent/new-relic-guided-install-overview/) | ✅ Yes | Public Preview | Public Preview | | [**Apache**](https://docs.newrelic.com/install/apache/) | ✅ Yes | Public Preview | Public Preview | | [**Flex**](https://docs.newrelic.com/docs/infrastructure/host-integrations/host-integrations-list/flex-integration-tool-build-your-own-integration/) | ✅ Yes | Public Preview | Public Preview | | [**Memcached**](https://docs.newrelic.com/install/memcached/) | ✅ Yes | Public Preview | Public Preview | | [**MySQL**](https://docs.newrelic.com/install/mysql/) | ✅ Yes | Public Preview | Public Preview | | [**NGINX**](https://docs.newrelic.com/install/nginx/) | ✅ Yes | Public Preview | Public Preview | | [**PostgreSQL**](https://docs.newrelic.com/install/postgresql/) | ✅ Yes | Public Preview | Public Preview | | [**Redis**](https://docs.newrelic.com/docs/infrastructure/host-integrations/host-integrations-list/redis/redis-integration/) | ✅ Yes | Public Preview | Public Preview | | [**New Relic OpenTelemetry Collector (NRDOT)**](https://docs.newrelic.com/docs/opentelemetry/nrdot/nrdot-intro/) | ✅ Yes | ✅ Yes | ⚠️ Experimental | | [**Fluent Bit**](https://docs.newrelic.com/docs/logs/forward-logs/forward-your-logs-using-infrastructure-agent/) | ✅ Yes | 🚫 No | 🚫 No | | [**New Relic Prometheus agent**](https://docs.newrelic.com/docs/infrastructure/prometheus-integrations/get-started/send-prometheus-metric-data-new-relic/) | ✅ Yes | 🚫 No | 🚫 No | | [**New Relic eBPF agent**](https://docs.newrelic.com/docs/ebpf/overview/) | ✅ Yes | ⚠️ Experimental | 🚫 No | | [**APM agents (.NET, Java, Node, Python, Ruby)**](https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started/introduction-apm/) | 🚫 No | 🚫 No | 🚫 No | > #### ⚠️ IMPORTANT > > Agent-specific permissions: Agent Control is designed to provide you with flexible permissions management. While Agent Control itself requires a certain level of access to function, the permissions it grants to individual agents are tailored to their specific needs. Below, you can find a breakdown of the permissions required for each agent type. ## Required permissions per agent type The following table lists the key permissions each agent type requires and the environments where it applies. | Agent type | Key permissions required | Environment | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | | **New Relic infrastructure agent** | Host-level access for system metrics and Kubernetes API access for cluster data. | Kubernetes / host-based | | **Apache** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **Flex** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **Memcached** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **MySQL** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **NGINX** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **PostgreSQL** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **Redis** | Executed by infra-agent with the same permissions. | Kubernetes / host-based | | **New Relic OpenTelemetry Collector (NRDOT)** | Permissions depend on specific receivers and exporters. Often requires Kubernetes API access for service discovery. | Kubernetes / host-based | | **Fluent Bit** | Read access to pod and container logs. | Kubernetes | | **New Relic Prometheus agent** | Permissions to discover and access service endpoints within the cluster for scraping metrics. | Kubernetes | | **New Relic eBPF agent** | Elevated privileges (for example, `CAP_SYS_ADMIN`) to load eBPF programs on the host kernel. | Kubernetes, Linux hosts (experimental) | | **APM agents (.NET, Java, Node, Python, Ruby)** | _Not currently supported by Agent Control._ | N/A | > #### ⚠️ NRDOT ON WINDOWS HOSTS IS EXPERIMENTAL > > The New Relic OpenTelemetry Collector (NRDOT) on Windows is available but not officially tested or documented by the NRDOT team. The default bundled configuration is designed for Linux and may produce warnings or errors on Windows (for example, from `filelogreceiver` paths). No default configuration is bundled for Windows — you must supply your own collector configuration. Use NRDOT on Windows only in non-critical or testing environments. > #### ⚠️ EBPF ON LINUX HOSTS IS EXPERIMENTAL > > The New Relic eBPF agent requires kernel-level dependencies (such as `linux-headers` matching the running kernel version) that Agent Control cannot automatically resolve on Linux hosts. If these dependencies are missing or mismatched, deployment may fail without a clear error. eBPF support on Linux hosts is available for Kubernetes environments only in production. Use eBPF on Linux hosts only in non-critical or testing environments. > > eBPF is **not supported** on Windows hosts. ## Configuring Fluent Bit on hosts On hosts, Fluent Bit isn't deployed as its own top-level agent type (see the support table above). Instead, when log forwarding is enabled, Fluent Bit is spawned and managed by the **New Relic infrastructure agent** itself, the same way as when it's installed standalone. Agent Control only changes _where_ the infrastructure agent, its data, and the Fluent Bit binary and plugin live on disk. For how to configure log forwarding itself (`logging.d/*.yml` syntax, inputs, filters, attributes, and so on), see: - [Enable log management](https://docs.newrelic.com/docs/logs/forward-logs/enable-log-management-new-relic) - [Forward logs with Fluent Bit](https://docs.newrelic.com/docs/logs/forward-logs/logs-fluent-bit) ### Where to put your configuration The only Agent-Control-specific detail is where log forwarding files go: they land in the sub-agent's `logging.d` folder, one entry per log source, via the `config_logging` field of the infrastructure agent's config. Set it directly in the sub-agent's config (for example, its `local_config.yaml`) and send that to Agent Control: ```yaml config_logging: syslog.yaml: | logs: - name: syslog file: /var/log/syslog attributes: logtype: linux_syslog app.yaml: | logs: - name: app-log file: /var/log/app.log attributes: service: api env: production ``` ### Where Fluent Bit lives, and how it's updated | OS | Details | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Linux | Installed by your distro's package manager as a dependency of the agent-control package, so it's updated the same way as any other OS package, independently of Agent Control and infrastructure agent version bumps. | | Windows | Ships bundled with the infrastructure agent. It's updated whenever Agent Control updates the infrastructure agent — there's nothing separate to install or upgrade. |