Architecture

The MTG Virtual Appliance consists of Management and the appliance nodes that run Enterprise Resource Security, ERS. Management installs and administers one appliance deployment. Initialize ERS after installing the appliance.

See Technology choices for how the platform components work and Security and hardening for built-in protections and operator responsibilities.

Administrator access through Management is separate from ERS client access and optional external integrations.
Figure 1. Management and the appliance have separate responsibilities.

Components and Responsibilities

Component Purpose Operator entry point

Management host

Runs Management using the supplied Fedora CoreOS ISO or Docker/Podman on an operator-maintained host. Provides persistent storage, networking, time synchronization and HTTPS configuration.

ISO: hypervisor console and host SSH. Container: operator host and container-runtime commands.

Management application

Provides installation, configuration, updates, backups, recovery and diagnostics. It runs its own services inside the Management container in either deployment option.

Management HTTPS URL and Management administrator sign-in.

Appliance nodes

Run Talos Linux, Kubernetes, appliance services and the ERS workload. Their system, database and data disks are separate from Management storage.

Management; the generated administrative access material for advanced operations.

ERS

Provides the configured MTG application services and PKI. ERS interfaces, HSM connections and application credentials have their own configuration.

ERS setup in Management, then the configured application endpoints.

Choose Docker, Compose or Podman on an operator workstation or operator-created VM, or the Management ISO VM. Both provide the same application. For containers, retain the volume mounted at /var and the TLS directory.

For the ISO option, the Management ISO remains attached and first in its VM’s boot order. The Management state disk contains persistent data, not an installed operating system. Each boot starts the Management software embedded in the attached ISO and reuses valid state.

Appliance nodes follow a different lifecycle. They first boot the matching Talos artifact into maintenance mode. Management discovers them, asks you to approve their identities and disks, and installs the appliance onto those disks. Give their intended OS disk first boot priority.

Topology

The installation wizard offers Standalone and Three nodes. Standalone has one appliance node and no node redundancy. Three nodes uses three control-plane nodes. Keep Management separate from the selected appliance nodes; it does not count as an appliance node.

Choose the deployment profile agreed for your workload and release. Three nodes can still fail together if they share hypervisor storage, networking or a site. See Deployment requirements for capacity planning.

Network Identities

Keep these identities distinct when planning DNS, routing and certificates:

  • The Management hostname and HTTPS port identify the Management web application. The host’s IP address and its private internal node address are separate settings.

  • Each appliance node has its own name and IPv4 address. Management derives administrative connections from these addresses.

  • The application load-balancer address and application hostname expose ERS.

  • Kubernetes API connections use node IPs on port 6443. Initial configuration uses the first node; Management retains all node addresses and selects a reachable authenticated node when establishing access.

  • Talos API access uses the appliance node addresses. It is separate from the Kubernetes API endpoint.

Use Ports and protocols to plan the connections between operator workstations, Management, appliance nodes and external services.

Configuration and Connectivity

Management publishes the appliance’s desired configuration through GitOps. The appliance reconciles that configuration into running services. After saving or publishing configuration, check the affected workloads in the task and health views. Saving or publication alone does not confirm their health.

Management’s sign-in session and its connection to the appliance are separate. A cluster access lease lets Management use the uploaded artifact bundle for six hours. During that lease, Management opens external access to the Kubernetes API and node registries; Talos remains the authenticated control path between leases. After access expires or Management restarts, an operator can reconnect using the retained artifact bundle. The appliance can continue running while Management is disconnected.

Installation and Recovery Material

The Management ISO or container image starts Management. A release bundle installs one appliance release, and the matching Talos boot artifact starts the target nodes. These are separate inputs.

Installation produces a sensitive artifact bundle containing administrative access and configuration. Retain it outside Management. A backup bundle captures appliance state for recovery; it does not replace the artifact bundle. Losing Management and losing appliance data require different recovery procedures.