Hyperterse is a stateless, single-binary server — a natural fit for Kubernetes deployments. Each pod runs one instance ofDocumentation Index
Fetch the complete documentation index at: https://docs.hyperterse.com/llms.txt
Use this file to discover all available pages before exploring further.
hyperterse serve from the pre-built artifact image.
Deployment manifest
Service
Expose the deployment internally or externally: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
initialDelaySecondsto 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 increasingreplicas. 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.