On-Prem Deployment Specifications
Complete the Prerequisites first. The Middleware team will provide the installation guide.
Below are the deployment specs (nodes, IPs, ports, URLs) usually needed for internal approval by your infrastructure and security teams.
Compute#
| Tier | Daily ingest | Nodes (AWS) | Nodes (Azure) | Total capacity |
|---|
| Evaluation | up to 25 GB/day | 3 × m6i.xlarge | 3 × D4s_v5 | 12 vCPU / 48 GB |
| Standard | up to 500 GB/day | 4 × m6i.2xlarge | 4 × D8s_v5 | 32 vCPU / 128 GB |
| High volume | ~1 TB/day | 6 × m6i.2xlarge | 6 × D8s_v5 | 48 vCPU / 192 GB |
| Item | Spec |
|---|
| Kubernetes version | v1.25 or newer |
| Node root disk | 100 GB per node (50 GB is enough for the evaluation tier). Sized for container images |
| Optional database node pool | 1 node, 8 core / 32 GB, taint dedicated=database:NoSchedule (ClickHouse tolerates it; set clickhouse.clusters.db1.nodeSelector to pin ClickHouse there) |
| Pod count | ~30 pods at baseline; autoscaling can add up to ~45 more under load |
Storage#
| Item | Spec |
|---|
| Block storage (persistent volumes) | ~260 GB with the default volume sizes, default storage class with dynamic provisioning |
| Object storage | 1 S3 bucket / Blob container; data older than 14 days moves there and is kept for the retention period (default 365 days), so it grows with daily ingest × retention |
| Object storage access | Access key scoped to the Middleware bucket only |
IP Addresses#
| Purpose | Count |
|---|
| Load balancer | 1 (public, or internal if agents and users reach it privately) |
| Nodes | 3-6 (per compute tier) |
| Pod IPs — EKS default CNI only | Reserve 128-256 free IPs: ~40 pods at baseline (~30 platform + Kubernetes system pods), up to ~90 at peak, and AWS networking holds some spare IPs per node. Can be tuned lower if subnets are tight |
| Pod IPs — overlay CNI (AKS overlay, kubenet) | None from your subnets; only node + load balancer IPs |
| Recommended subnets (EKS) | 2 subnets in different availability zones, 256 IPs (/24) each. EKS requires 2 zones at cluster creation; run all nodes in a single zone (avoids cross-zone transfer costs and volume-affinity issues) |
Ports#
| Direction | Port | Source / Destination | Purpose |
|---|
| Inbound | 443/TCP | Agent networks + UI user networks → load balancer | Telemetry ingest (OTLP over TLS) and web UI |
| Inbound | 443/TCP | Installer workstation → Kubernetes API endpoint | helm / kubectl during install |
| Outbound | 443/TCP | Cluster → URLs listed below | Image pulls, storage, email |
No other inbound ports are required. All service-to-service traffic stays inside the cluster.
Outbound URLs#
| URL | Purpose |
|---|
ghcr.io | Middleware images + helm chart |
docker.io, registry-1.docker.io | Third-party images |
docker.redpanda.com | Third-party images |
S3 / Blob endpoint (e.g. s3.<region>.amazonaws.com or <account>.blob.core.windows.net) | Telemetry storage |
app.middleware.io | Outgoing emails (alerts, user invites, password resets) |
DNS & TLS#
| Item | Spec |
|---|
| DNS | 1 record (A or CNAME) pointing your Middleware domain to the load balancer |
| TLS certificate | Issued for that domain; terminated by Middleware's HAProxy behind the load balancer. Agents must trust the issuing CA |
Want to deploy Middleware in your own environment? Get in touch with us via our Contact Us or join our Slack channel.