Game & Application Server Hosting
Run dedicated game servers, real-time backends, WebSocket servers and background workers in isolated containers. Choose TCP, UDP or both, add secure WebSocket if you need it, and scale out with a master-worker topology.
Server Hosting Plans
Each plan sets the CPU, memory, storage, monthly bandwidth, maximum build size and maximum instances per region for a server deployment.
Two ways to run your servers
Combined
One server per region that does everything. The simplest setup ideal for small games, a single real-time backend, a bot or a worker process.
Master-Worker
A master server in each region coordinates a fleet of worker servers. Workers scale up and down automatically on CPU and memory thresholds, and your master is told about every change through signed webhooks. Ideal for matchmaking plus game-session servers.
What's Included
TCP, UDP or both
Expose one port over TCP, UDP or both protocols at once – whatever your networking library needs.
Secure WebSocket (optional
Turn on wss:// and the platform terminates TLS for you, so browser and WebGL clients can connect securely.
Stable addresses
Every server gets its own hostname and port. Clients look up where to connect through the Public API instead of hardcoding IP addresses.
Autoscaling (master-worker)
Set minimum and maximum worker counts per region plus CPU and memory thresholds. Sustained load adds workers; sustained quiet removes them.
Rolling updates without kicking players
When you deploy a new build, new servers start alongside the old ones. Old servers stop receiving new players and are given a drain period so current sessions can finish.
Environment variables
Configure your server with your own environment variables. The platform also injects useful values such as the region and role of each server.
Logs, metrics and events
Tail live logs, download log archives, and watch CPU, memory and bandwidth per deployment.
Isolated and resource-limited
Each account runs on a private network and every container has enforced CPU, memory and disk limits
Supported platforms
| Platform | Versions |
|---|---|
| Unity | Headless Linux server builds |
| .NET | 8, 9 |
| Node.js | 20, 22 |
| Python | 3.11, 3.12 |
| Java | 17, 21 |
| Go | Latest stable |
| Rust | Latest stable |
Upload your build as a .zip from the dashboard or the CLI. Large builds are uploaded in parts, and the maximum build size depends on your plan.
Good to know
-
Server disk is temporary. Anything a server writes to its own disk is lost when it is redeployed or replaced. Store persistent data in a database.
-
Draining servers keep running and keep being charged until their drain period ends or you release them early through the Public API.
-
Stopped servers keep their reserved resources and continue to be charged. Delete a deployment to stop its charges.
-
Custom domains are not available for server deployments; use the hostname the platform gives each server.
Frequently Asked Questions
Everything you need to know about MultiConnect Cloud.
Yes. Any long-running process works – WebSocket servers, chat or real-time backends, background workers, bots and custom TCP/UDP services.
In master-worker mode you set a minimum and maximum number of workers per region and CPU and memory thresholds. When usage stays above a threshold for a few minutes, a worker is added; when it stays low for longer, a worker is removed – never below your minimum or above your maximum. Combined mode runs one server per region and does not autoscale.
Your game client or backend calls the Public API with an access key to get the current address and port to connect to. Keys can be marked “client-distributable” so they are safe to ship inside a game build – they can only read connection details.
Players on old servers are not disconnected. The new build starts first, new players go to it, and old servers drain for a grace period before they are removed.
Headless (dedicated server) Linux builds.