Start with what the process is actually holding. Tessera's own accounting puts a proxied session at about 256 KB of copy buffers plus six to ten goroutines at roughly 8 KB of stack each, rounded to 320 KB, sitting on a base Go process of about 30 MB [3][4]. That figure is indexed to connections open right now, not to headcount. Run the 200-person organisation through it. The planning rule in the post is that 10 to 20 percent of a team is connected on a normal working day, which is 20 to 40 concurrent sessions [5]. At 320 KB apiece that is 6.4 to 12.8 MB of live session data [1]. Add the base process and you are near 36 to 43 MB, and Go's residency behaviour roughly doubles it, so expect something like 73 to 86 MB resident [2]. A 512 MB VM is about six times that [7]. That is a large cluster for a total of 13 MB of buffers. The doubling is the part to understand before you write a limit. Go does not hand memory back to the operating system promptly, and at the default GOGC=100 the collector lets the heap grow to roughly twice the live set before it collects, so resident memory settles at about double the arithmetic [8]. The author treats that gap as headroom for spikes rather than a hidden cost [9]. The chart's defaults agree with him: requests 256Mi, limits 1Gi [10]. For the 200-session case his arithmetic is 94 MB [7], which lands near 188 MB resident, making 1Gi about five times the expected figure [3]. These are one vendor's numbers, disclosed as such by the author, who says the reasoning applies to any proxy in a session path [1]. Two constants have to hold for the 320 KB to transfer: buffer size per session and goroutine count per session [3]. A proxy that allocates a megabyte per direction, or an OS thread per session, has a different constant, and the GOGC doubling is specific to a Go runtime [8]. That is why the two questions the post tells you to ask, per-session memory and base process size, are the right ones, and why the "thousands of users" line answers neither [11][2]. The proxy terminates TLS with the client and runs SSH to the target, so every byte is encrypted and decrypted twice [12]. AES-NI does that in hardware on any CPU of the last decade, and the post's figure is one vCPU per 50 concurrent sessions, four for 200-plus [13]. Forty sessions therefore fits inside a single vCPU [6]. The traffic is the real limit: everything crosses the controller twice, so moving N bytes costs 2N on its interface, and that interface saturates first [15]. Interactive shells are a few KB/s each, single-digit Mbit/s even at 200 sessions [16]. One RDP session runs 0.5 to 5 Mbit/s and is sustained, so 20 of them is 100 to 200 Mbit/s through the controller [17]. At the top of that range a single RDP session, doubled, is 10 Mbit/s, which on its own exceeds the whole 200-shell load [5]. So the link gets sized from RDP alone [18], while memory and CPU come off the session count. Sustained file transfer sits in the same non-interactive category [14]. Latency is separate from all of it. The double hop adds a round trip to every keystroke echo, so a controller in a different region from its targets is a tool users will call laggy, correctly, and three regions of targets argues for three controllers [19].
