How many servers do you need?
Enter your hardware spec and user count. IMTerm calculates exactly how many nodes you need - and enforces that limit at runtime so your load balancer never sends users to an overloaded server.
The formula
Every number in the calculator is derived from a single measured fact: each IMTerm terminal session uses approximately 32 MB of RAM for its goroutine stack, screen buffer, and WebSocket state. We measured this on a real IBM i 7.5 (pub400.org) under sustained load with 300 active sessions.
Available RAM = Total RAM - OS reserve Linux (RHEL/AlmaLinux): 4 GB reserved for OS Windows Server: 6 GB reserved for OS Windows Server + roles: 8 GB reserved for OS Safe sessions per node = floor(Available RAM (GB) / 0.032) * 80% 0.032 GB = 32 MB = measured per-session footprint The 20% headroom covers connection storms and GC pauses. Nodes needed = ceil(peak users / safe sessions) + 1 spare The spare node enables zero-downtime rolling upgrades.
Quick reference (Linux / RHEL / AlmaLinux)
| Hardware | Safe sessions | 500 users | 2,000 users | 5,000 users |
|---|---|---|---|---|
| 8 vCPU / 16 GB | 300 | 3 nodes | 8 nodes | 18 nodes |
| 8 vCPU / 32 GB | 700 | 2 nodes | 4 nodes | 9 nodes |
| 16 vCPU / 32 GB | 700 | 2 nodes | 4 nodes | 9 nodes |
| 16 vCPU / 64 GB | 1,500 | 2 nodes | 3 nodes | 5 nodes |
All node counts include +1 spare. CPU is not the primary constraint - an 8 vCPU server handles 300+ sessions with CPU below 20% under normal conditions.
Why CPU is not the constraint
Terminal sessions are almost entirely idle between keystrokes. A TN5250E session sends a few hundred bytes per keystroke and receives one screen update in response. The server does no computation - it forwards bytes between the browser WebSocket and the AS/400 TCP connection. An 8 vCPU server handles 300+ sessions with CPU staying below 20% under normal conditions.
What makes IMTerm different
Capacity-aware health endpoint
When a node reaches its configured maximum sessions, the health endpoint returns HTTP 503. Your load balancer automatically stops routing new users to that node - no configuration required.
GET /api/health -> 503 {"status":"full","capacity_pct":97}
Automatic load distribution
Users are automatically distributed across nodes by the load balancer. No sticky sessions required for standard use. The admin console on any node shows all sessions across all nodes.
Zero-downtime upgrades
The +1 spare node in the formula exists specifically for rolling upgrades. Drain a node, upgrade it, bring it back. Users never experience downtime. This works for 2 nodes or 20.
Ready to deploy IMTerm?
60-day evaluation available. Use the calculator above to size your cluster
before you begin, then run imterm-setup
on each node - it detects your RAM and walks you through the configuration.