Skip to main content

Deploy the Registry Server

System requirements​

  • Kubernetes: current and two previous minor versions are supported. Production workloads should run on a cluster with at least one node providing 1 vCPU and 1 GB of memory available for the Registry Server pod.
  • PostgreSQL: version 14 or later. The server runs database migrations automatically on startup, so the migration user needs schema-modification privileges. See Migration user privileges for the full privilege model.
  • Persistent storage (recommended for Git sources): a volume mounted at /data avoids re-cloning repositories on every container restart.
  • Network access: outbound connectivity to your configured sources (Git hosts, upstream registries, file URLs) and to the PostgreSQL server.

Deployment methods​

The Registry Server can be deployed in Kubernetes using three methods. Choose the one that fits your environment:

MethodDescription
ToolHive OperatorManage the Registry Server lifecycle through MCPRegistry CRDs
HelmDeploy a standalone Registry Server using its dedicated Helm chart
Manual manifestsDeploy directly using raw Kubernetes manifests

ToolHive Operator​

Deploy and manage the Registry Server using MCPRegistry custom resources. The ToolHive Operator watches for these resources and creates the necessary infrastructure automatically.

See Deploy with the ToolHive Operator for a complete guide.

Helm​

Deploy the Registry Server directly with the official Helm chart from the toolhive-registry-server repository. Use this method when you want to manage the Registry Server like any other Helm release without installing the ToolHive Operator.

See Deploy with Helm for a complete guide.

Manual manifests​

Deploy the Registry Server directly using raw Kubernetes manifests. This approach gives you full control over the deployment configuration.

See Deploy manually for instructions.

Next steps​

Pick the deployment method that fits your environment and follow its guide:

Then configure the rest of the stack: