Skip to main content
Hyperterse is a stateless, single-binary server — a natural fit for Kubernetes deployments. Each pod runs one instance of hyperterse serve from the pre-built artifact image.

Deployment manifest

Service

Expose the deployment internally or externally:
For external access, use an Ingress controller or change the type to LoadBalancer.

Health probes

Hyperterse exposes /heartbeat on the configured port. Use it for both liveness and readiness probes:
  • Liveness — Restart the pod if the process is unresponsive. Set a reasonable initialDelaySeconds to allow connector initialization.
  • Readiness — Remove the pod from the service until all connectors are ready. The heartbeat endpoint only responds after the server is fully initialized.

Secrets

Store credentials in Kubernetes Secrets and inject them as environment variables. Never include connection strings or API keys in your container image or ConfigMaps.

Scaling

Hyperterse is stateless. Scale horizontally by increasing replicas. Each instance maintains its own in-memory cache — no shared state between pods. If your tools use MCP session management, enable sticky sessions through your ingress controller or service mesh to send subsequent requests from the same session to the same pod.

Security hardening

The manifest above follows security best practices:
  • Read-only root filesystem prevents runtime modifications to the binary or manifest.
  • Non-root user (UID 1001) limits the blast radius of a container escape.
  • Resource limits prevent a single pod from consuming all node resources.
See Production hardening for additional recommendations.