For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

See how the Solo Enterprise for agentregistry control-plane components appear and integrate for each runtime you connect.

A single Solo Enterprise for agentregistry installation—one registry control plane—is designed to manage many runtimes at once and to govern the AI artifacts across all of them. The control plane is the same set of components no matter which runtimes you connect: a registry server backed by one PostgreSQL database and one ClickHouse database, with one or more OpenTelemetry Collectors for trace ingestion, and authentication delegated to an identity provider. What changes from runtime to runtime is where those components run and how the registry reaches the runtime. This page shows that mapping for each runtime. For the components themselves, see Architecture.

Solo Enterprise for kagent

For Kubernetes, the registry integrates with the Solo Enterprise for kagent control plane that runs in your cluster. One registry can connect to many kagent clusters at once.

How the components map: The diagram collapses everything into one cluster to keep the component relationships readable, but the pieces are independent: PostgreSQL, ClickHouse, and the identity provider can be external managed services, and the registry control plane and the kagent runtime can even run in separate clusters.

• Registry server and its state stores. The registry server is the control plane: it serves the UI and API, holds the catalog of agents, MCP servers, deployments, and policies, and drives every action against connected runtimes. It persists that state in PostgreSQL (shown in-cluster, but treatable as an external managed database), while a runtime is modeled internally as a connection—which is how one registry governs many kagent clusters at once.
• Identity provider. Keycloak is the single OIDC identity provider for this runtime: it authenticates the Registry UI, arctl CLI, and REST API clients into the registry, and it is the issuer the runtime itself trusts. That identity is what the registry uses to apply access control—it maps each caller’s JWT group claim to a role and authorizes what the user may read, publish, deploy, or invoke (through the chat UI) against the AccessPolicy resources you define. Any standards-compliant OIDC provider (Okta, Auth0) works in its place, in-cluster or external.
• kagent controller. The registry server calls the kagent controller’s management API to create and manage workloads, translating each catalog entry into the runtime’s native resources—a kagent Agent for agents and an MCPServer for MCP servers—which the controller then materializes as pods in your team namespaces. It authenticates these calls with its own OIDC service identity: a client-credentials service token minted from your IdP, carrying a group claim that kagent’s RBAC maps to a role (for example, agentregistry → global.Writer); no end-user credentials are used for deploy or management operations. The relationship is two-way—beyond pushing deploys, the registry polls the runtime’s inventory on a regular interval (and immediately after each deploy) to discover agents deployed by other means and to detect drift between the catalog and what actually runs.
• Workload images. On kagent you build the agent and MCP-server images yourself and push them to a container registry of your choice; at deploy time the cluster’s kubelet pulls them from there, using image-pull secrets you configure on the runtime for private registries. Neither the registry nor kagent builds or stores images—the key difference from cloud runtimes, where the platform builds the container for you.
• The workloads (agent and MCP-server pods). These are your code, running in team namespaces as the deployed agents and MCP servers. They are what the runtime actually executes; everything else in the diagram exists to deploy, secure, or observe them.
• Runtime authorization (agentgateway waypoint). To govern what deployed workloads may do at runtime—which agent can call which other agent (A2A) and which MCP tools it can invoke—kagent enforces your policies in the data plane through an agentgateway waypoint. Your registry AccessPolicy is translated into a kagent AccessPolicy, the deployed workloads are enrolled with the waypoint so their traffic is captured, and the policy is pushed to it as configuration via xDS—so every agent-to-agent and agent-to-MCP call passes through the waypoint and is allowed or denied before reaching its target. Because this runs in the data plane it requires Solo Enterprise for Istio (the ambient mesh that hosts the waypoint) and Solo Enterprise for agentgateway; it is an opt-in layer—the base kagent runtime deploys and runs agents without it.
• Telemetry (OTel Collector → ClickHouse). The deployed pods push OTLP traces to the OTel Collector, which writes them to ClickHouse to back the Tracing view (the dashed return arrow). On kagent the collector is a plain in-cluster ClusterIP Service, since the workloads run alongside it and need no external exposure.

AWS Bedrock AgentCore

For AWS, the registry connects to your AWS account and deploys agents and MCP servers as Bedrock AgentCore runtimes. The control plane runs in an EKS cluster; the runtimes and their managed gateway run in your AWS account, outside the cluster.

How the components map: The Solo Enterprise for agentregistry control plane is deployed on a Kubernetes (EKS) cluster in your AWS account. For simplicity the diagram shows PostgreSQL and ClickHouse inside that cluster, but they can be external managed services—PostgreSQL on Amazon RDS, for example. What’s specific to this runtime is that the workloads run on AWS Bedrock AgentCore: the agents and MCP servers you deploy run as AgentCore runtimes, and the registry provisions a managed gateway on an EC2 instance to broker their traffic. The EKS cluster, the AgentCore runtimes, and the managed gateway all run in the same VPC.

• Registry server and its state store. The registry server is the control plane, running in the EKS cluster: it serves the UI and API, holds the catalog of agents, MCP servers, deployments, and policies, and drives every action against the AWS runtime. It persists that state in PostgreSQL—shown in-cluster, but treatable as an external managed database such as Amazon RDS. For more information, see BYO PostgreSQL database.
• Identity (one or two OIDC providers). The registry has no built-in OIDC; it relies on your provider (Keycloak, Amazon Cognito, or Okta/Auth0). Two identity roles are in play, and they can be a single provider or two separate ones: the registry OIDC authenticates the people, CLI, UI, and REST API that reach the registry and backs its access control over catalog actions, while the agent OIDC authorizes calls to the deployed agents. They serve different purposes—the token that logs you into the registry is not the token that authorizes an agent call.
• AWS access (IAM, not OIDC). How the registry reaches AWS at all is IAM-based. The registry pod authenticates to AWS with EKS Pod Identity (or static IAM user credentials), then assumes a cross-account IAM role—created from a CloudFormation template and scoped with an external ID—for every AWS operation. This is the AWS-specific foundation that the deploy, build, and gateway steps below all rely on.
• Build and deploy (S3 → build → ECR). To deploy, the registry calls the AWS Bedrock AgentCore control-plane API (under the assumed role) to create a runtime. When you deploy from source, it first packages the source and uploads it to an S3 bucket; AWS builds a container image and stores it in ECR; the AgentCore runtime then pulls that image and runs it in your VPC. If you bring a prebuilt image, the registry skips S3 and points the runtime straight at your ECR image. Throughout, it tracks each runtime’s status to reflect deployment progress in the catalog.
• The workloads (Bedrock AgentCore runtimes). Your agents and MCP servers run as managed AWS Bedrock AgentCore runtimes, not pods you operate. They run outside the EKS cluster but inside the same VPC—which is why their traffic and telemetry cross the network back to the control plane (the next two bullets).
• Managed gateway (EC2), runtime enforcement. The registry provisions a managed gateway on EC2—a Solo Enterprise for agentgateway proxy plus an agentregistry-sts token service—that carries all agent-to-MCP traffic and enforces your access policies at runtime, validating each caller against the agent OIDC. It’s the AgentCore counterpart to kagent’s waypoint: the same policy model, a different enforcement point (a managed EC2 gateway instead of a mesh waypoint, and no Istio dependency). The registry configures it indirectly through AWS AppConfig rather than connecting to it directly.
• Telemetry (OTLP → OTel Collector → ClickHouse). Because the runtimes run outside the cluster, they export OTLP traces over the network back to the OTel Collector in the control plane, which writes them to ClickHouse for the Tracing view. This is why the collector—and the identity providers—must be reachable from the VPC; on AWS that typically means exposing the collector through a load balancer rather than the cluster-internal service kagent uses.

Microsoft Azure and Copilot Studio

For Azure AI Foundry and Microsoft Copilot Studio, the registry connects to your Microsoft tenant to inventory the agents that already run there.

How the components map: This is a discovery integration: the registry connects to your Microsoft cloud and reads the agents that already run there—it does not deploy them, run them, or route their traffic. As a result, only two control-plane components take part: the registry server and PostgreSQL, which caches the discovered inventory. Because nothing is deployed or traced, ClickHouse and the OTel Collector play no part in this integration. The control plane can run in any Kubernetes cluster; it only needs outbound access to your Microsoft tenant.

• Registry server and inventory cache. The registry server is the control plane: it serves the UI and API, holds the catalog, and runs the discovery sync loop. It caches the discovered agents in PostgreSQL, which is also its state store and can be an external managed database. These two are the only components active in this integration—there is nothing to build, deploy, or operate in your own infrastructure.
• Identity. Two identities are involved. A registry identity provider (Keycloak, Cognito, Okta/Auth0, and so on) authenticates the people, CLI, UI, and REST API that reach the registry and governs what they can do. Separately, a Microsoft Entra app registration is the service identity the registry uses to reach your Microsoft tenant: you create the app, grant it read access to the target service, and store its client secret in the registry, which then uses the client-credentials grant to obtain a token for each sync.
• Discovery and sync, the core of this runtime. Instead of deploying agents, the registry periodically calls your Microsoft cloud to list the agents that already exist and caches them as read-only Instances, each with provider metadata and a deep link back to the Microsoft portal. Applying the runtime triggers an initial sync, and the runtime status reports whether the last sync succeeded. The registry cannot deploy or remove agents on these runtimes—it only reflects what Microsoft reports.
• Target service — Azure AI Foundry vs. Microsoft Copilot Studio. The two runtimes differ only in what the registry reads. For Azure AI Foundry, it lists the agents in your Foundry project (the Entra app needs the Foundry User role on that project). For Microsoft Copilot Studio, it lists the agents in your Power Platform environment through the Dataverse Web API (there the Entra app must be a Dataverse application user with read access to the bots—a role separate from any subscription or resource-group role). You register one runtime per project or environment, and a single registry can track many of them; everything else—the Entra identity, the sync loop, the cached read-only inventory—is identical.
• The agents (run in Microsoft). The agents themselves live and run entirely in Azure AI Foundry or Copilot Studio. The registry gives you a single place to inventory and monitor them across projects and environments without owning their lifecycle—which is what keeps this integration lightweight.

Solo Enterprise for agentgateway (virtual runtime)

The Virtual runtime lets you take MCP servers that already run somewhere else—an in-cluster service URL, or a fully external, public SaaS MCP endpoint—and expose them through a Solo Enterprise for agentgateway proxy at stable, registry-managed paths. You catalog the remote server and create a Deployment against the Virtual runtime; the registry translates that into Gateway API routing (a backend plus a route) on the gateway, using route delegation. No image is built and no workload is run—the registry only manages routing and access in front of servers it doesn’t host. (A virtual-default runtime is even created automatically at startup.)

How the components map: This runtime hosts nothing of its own—it puts a managed front door in front of MCP servers that run elsewhere. The pieces on your side stay lightweight: the registry server with its PostgreSQL catalog, your identity provider, and a user-managed agentgateway proxy. The registry programs the gateway’s routing but stays out of the request path, so live MCP traffic flows client → gateway → remote server. There’s no image build, no workload, and no telemetry pipeline of its own; ClickHouse and the OTel Collector come into play only if the remote servers emit traces.

• Registry server and its catalog store. The control plane holds the catalog—the remote MCP servers you register and their Deployments—in PostgreSQL, and runs the Virtual deployment adapter that turns each entry into gateway routing configuration. It runs in any Kubernetes cluster.
• Identity. A registry OIDC provider (Keycloak, Cognito, Okta, and so on) authenticates the people, CLI, UI, and REST API that reach the registry and governs catalog access. Separately—and optionally—the gateway can enforce an access policy on the exposed MCP calls (JWT claims such as audience or email), so you can gate who may call each remote server at the edge.
• Expose and route, the core of this runtime. Instead of deploying, the registry fronts remote MCP servers through a user-managed agentgateway using Gateway API route delegation. For each remote server and its Deployment it writes two pieces of routing configuration: an agentgateway backend (the upstream—host, port, and path; TLS when the URL is https; and a header filter when the server needs a credential such as a bearer token) and a child HTTPRoute (the path the server is exposed on). The server becomes reachable at a stable path under the delegated prefix (for example, /registry/github), reported back in the deployment status. Only servers that declare a remote endpoint qualify.
• The agentgateway (data plane). A user-managed Solo Enterprise for agentgateway proxy—a Gateway API Gateway plus a parent HTTPRoute—carries the live MCP traffic: it accepts client requests, delegates by path to the registry’s child routes, and proxies to the remote server, applying any access policy on the way. Because this is a north-south gateway rather than a mesh waypoint, it needs Solo Enterprise for agentgateway and the Gateway API CRDs—but not Istio.
• The remote MCP servers. The actual MCP endpoints live and run elsewhere—an in-cluster service, or an external, public SaaS MCP server. The registry never hosts them; it only catalogs and exposes them.

For more information, see Remote MCP gateway.

Next steps