Este conteúdo não está disponível no idioma selecionado.

Chapter 1. Red Hat Edge Manager architecture


Designed for scalability and resilience, Red Hat Edge Manager leverages a dedicated device agent to manage the operating system and workloads. This architecture ensures reliable deployment and monitoring across extensive fleets, maintaining operational integrity even when network connectivity is limited or intermittent.

By deploying a Red Hat Edge Manager agent to a device, the agent autonomously manages and monitors the device while periodically communicating with the Red Hat Edge Manager service to check for new configurations and to report device status.

Red Hat Edge Manager supports image-based operating systems. You can include the Red Hat Edge Manager agent and the agent configuration in the image that is distributed to the devices.

Image-based operating systems allow the agent to initiate a transactional update of the image and to roll back to the previous version in case of an update error.

Red Hat Edge Manager architecture has the following main features:

  • Agent: A lightweight process on the device that autonomously polls the service for updates, implements the desired state, and manages local workloads even during network outages.
  • Service: The central control plane responsible for managing device inventory and coordinating fleet-wide configurations. To support these operations, the service includes:

    • API server: The secure gateway that handles all communication between the service, administrative tools, and the distributed agents.
    • Database: The persistent storage layer that holds the current device registry, enrollment information, and the target state definitions for the fleet.
  • Image-based operating system: An immutable Linux distribution using bootc. This enables transactional, versioned updates that can be safely rolled back, ensuring maximum reliability for edge deployments.
  • Device: An individual hardware unit or virtual machine running the agent. It maintains local state awareness, independently applying configurations and reporting its unique health metrics back to the service.
  • Device fleet: A logical grouping of devices managed as a single entity. Fleets allow you to roll out updates and policies to thousands of devices simultaneously with granular visibility.

1.1. Red Hat Edge Manager agent and service

The Red Hat Edge Manager agent is a process running on each managed device that periodically communicates with the Red Hat Edge Manager service.

The Red Hat Edge Manager agent is responsible for the following tasks:

  • Enrolling its device into the service.
  • Periodically checking with the service for changes in the device specification, such as changes to the operating system, configuration, and applications.
  • Applying any updates independently from the service.
  • Reporting status of the device and the applications

The Red Hat Edge Manager service acts as the central hub for your edge operations, functioning as a reliable bridge between your core systems and your distributed devices. It manages the entire life of a device from the moment it’s securely connected to the network to the ongoing tracking of its health and activity across the fleet.

The service communicates with a database that stores the device inventory and the target device configuration. When communicating with the service, the agent polls the service for changes in the configuration. If the agent detects that the current configuration deviates from the target configuration, the agent attempts to apply the changes to the device.

When the agent receives a new target configuration from the service, the agent does the following tasks:

  1. Stage Resources: To ensure resilience against network failure during the update, the agent pre-downloads all required assets—including the operating system image and application container images—directly to local storage.
  2. Update Operating System: The agent delegates the operating system update to bootc, ensuring a transactional image-based transition.
  3. Apply Configuration: The agent updates the local file system by overlaying configuration files provided by the service.
  4. Finalize Environment: If required by the update, the agent triggers a system reboot. If no reboot is necessary, it signals the relevant system services and applications to reload their configurations.
  5. Update Workloads: The agent synchronizes and updates applications running on Podman or MicroShift.

If the update fails or the system does not return online after rebooting, the agent automatically rolls back to the previous operating system image and configuration.

Note

You can maintain fleet definitions in Git. Red Hat Edge Manager periodically syncs with the fleet definitions in the database.

1.2. Red Hat Edge Manager API server

The API server acts as the central communication hub, exposing secure endpoints that allow both users and agents to interact with the Red Hat Edge Manager service.

The API server exposes the following endpoints:

User-facing API endpoint
Users can connect to the user-facing API endpoint from the CLI or the web console. Users must authenticate with the configured external authentication service to obtain a JSON Web Token (JWT) to make HTTPS requests.
Agent-facing API endpoint
Agents connect to the agent-facing endpoint, which is mTLS-protected. The service authenticates devices using the X.509 client certificates.

The Red Hat Edge Manager service also communicates with various external systems to authenticate and authorize users, get mTLS certificates signed, or query configuration for managed devices.

1.3. Device enrollment

You need to enroll devices to a Red Hat Edge Manager service before you can start managing them. The Red Hat Edge Manager agent that runs on a device handles the device enrollment.

When the agent starts on a device, the agent searches for the configuration in the /etc/flightctl/config.yaml file. The file defines the following configurations:

  • The enrollment endpoint, which is the Red Hat Edge Manager service that the agent connects to for enrollment.
  • The enrollment certificate, which is the X.509 client certificate and key that the agent only uses to securely request enrollment from the Red Hat Edge Manager service.
  • Optional: Any additional agent configuration.

The agent starts the enrollment process by searching for the enrollment endpoint, the Red Hat Edge Manager service, that is defined in the configuration file.

After establishing a secure, mTLS-protected network connection with the service, the agent submits an enrollment request to the service.

The request includes a description of hardware and operating system of the device, a X.509 certificate signing request, and the cryptographic identity of the device.

The enrollment request must be approved by an authorized user. After the request is approved, the device becomes trusted and managed by the Red Hat Edge Manager service.

1.3.1. Enrollment methods

You can provision the enrollment endpoint and certificate to the device in the following ways:

Early binding: You can build an operating system image that includes the enrollment endpoint and certificate. Devices using an early binding image can automatically connect to the defined Red Hat Edge Manager service to request enrollment, without depending on any provisioning infrastructure.

The devices share the same long-lived X.509 client certificate. However, in this case, the devices are bound to a specific service and owner.

Late binding: You can define the enrollment endpoint and certificate at provisioning time instead of including them in the operating system image. Devices using a late binding image are not bound to a single owner or service and can have device-specific, short-lived X.509 client certificates.

However, late binding requires virtualization or bare metal provisioning infrastructure that can request device-specific enrollment endpoints and certificates from the Red Hat Edge Manager service and inject them into the provisioned system by using mechanisms such as https://cloud-init.io/, https://coreos.github.io/ignition/supported-platforms/, or https://anaconda-installer.readthedocs.io/en/latest/kickstart.html.

Note

Note: The enrollment certificate is only used to secure the network connection for submitting an enrollment request. The enrollment certificate is not involved in the actual verification or approval of the enrollment request. The enrollment certificate is no longer used with enrolled devices, as the devices rely on device-specific management certificates instead.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red Hat
Voltar ao topo