Can Gitpod horizontally scale a single workspace across multiple containers to reduce concurrent-edit latency?

Background

Gitpod workspaces run as single containers, and the collaboration model shares that container among all connected users. When multiple developers simultaneously edit large files, CPU and memory contention in the shared container can introduce measurable latency in Language Server Protocol responses and editor interactions. The documentation acknowledges this as a known limitation when more than two or three users collaborate actively.

Constraint

The control plane does not automatically redistribute load across multiple containers for the same workspace. Self-hosted installations can adjust Kubernetes resource quotas per workspace pod, but this only raises the vertical ceiling; it does not enable horizontal scaling of a single workspace's compute. Prebuilds accelerate startup but do not affect runtime contention.

Open question

Given the single-container architecture, is there a supported mechanism—or a planned enhancement—to partition a workspace's workload across multiple pods so that concurrent LSP connections and file operations can be served in parallel without resource contention? If not, what architectural changes would be required to make horizontal scaling of a single workspace feasible while preserving filesystem and process consistency?