Deployments
Learn about deployments and their lifecycle - concepts and best practices for deeper understanding.
🗺️ Orchestration
Start new servers within seconds to meet capacity demands with our cloud native edge computing approach. We treat servers as cattle rather than pets - replacing faulty instances entirely instead of nursing each one manually.
Reach out in Discord to learn about hybrid orchestration options and optimizing your hosting cost.
To fully understand all pros and cons, let’s compare various orchestration methods. Some games will use multiple methods of orchestration depending on game loop design.
Match-Bound
Short-lived (time-limited) servers scale down on match end, providing best cost performance ratio.
Sessions are typically automated through a Matchmaking service, which deploys servers just in time using strict rules, and optionally allows filling ongoing servers to boost match fill rates.
👍 Advantages
Best cost efficiency - scaling in real time to meet player demand minute by minute.
Lowest devops cost due to region-less hosting, Edgegap automates 99% of tasks.
Lowest ping due to 615+ sites in Edgegap’s public cloud infrastructure.
Fastest scale up (burst-ability) in case of unexpected traffic spike.
Highest standard of security and player cheating prevention (server authority).
Minimal impact of unexpected server crash on players, only affecting a single match.
👎 Disadvantages
Adopting a new orchestration mental model requires some ramp up effort initially.
Servers running longer than 24 hours will be automatically terminated.
🧩 Best Suited For
Latency-sensitive games - when netcode optimization can't overcome high ping:
First Person Shooters, Fighting Games, VR & XR (virtual and extended reality), …
Games with an upper limit on match duration by design,
Battle Royale, PvPvE, Coop Shooters, MOBA, Sports Games, ARPGs & Dungeon Crawlers, …
Regional Standby
Persistent world and social MMO game server lifespan often exceeds individual player sessions.
Sessions are usually assigned through a Server Browser based on player preference (automated by region or custom search), with horizontal deployment pre-scaling based on regional capacity.
👍 Advantages
Familiar and easy to understand, old-school approach for battle-scarred veterans.
Highest standard of security and player cheating prevention (server authority).
Easily predictable cost based on monthly commitment.
👎 Disadvantages
Higher hosting cost - each region requires one or more idle standby servers (burst capacity).
Higher devops cost - scaling, operations, and maintenance duplicated per region.
Regions with smaller player base experience high ping due to joining servers far away.
🧩 Best Suited For
Persistent worlds with user-generated content stored on server even when players go offline.
MMOs, Sandboxes with base building or object placement, Extraction Shooters, ...
latency-tolerant games - when server authoritative real-time physics aren’t required:
mobile games, Coop Games, TCGs/CCGs, Turn-Based Strategies, …
Asynchronous multiplayer, where server crashes have minimal impact on player experience:
race against ghosts, loot enemy base, timer-based building/farming games, …
applications with heavy initialization process - when preparing servers takes minutes.
Peer to Peer
Shift development efforts from dedicated servers to relay netcode for non-competitive games.
Related topics: listen servers, player-host authority, NAT punch-through.
👍 Advantages
Lowest hosting cost, requiring only Relay servers to solve NAT punch-through.
Lowest devops cost - maintenance required only for client builds and distribution channels.
Minimal impact of unexpected server crash on players, only affecting a single match.
Easy to implement and fast time to prototype, without any backend development required.
👎 Disadvantages
Increased peer-to-peer netcode development effort requiring concurrent programming skills.
Worst ping times and most sensitive to unfavorable network conditions (e.g. mobile internet).
Weakest security, vulnerable to man-in-the-middle attacks and session hijacking.
Risk dropping sessions when host leaves unless you implement custom host migration.
🧩 Best Suited For
Coop & casual games - when cheating doesn’t take away from fun or break the game,
Kids Games, Exploration Games, Adventures, …
See our Distributed Relays for service enabling peer to peer with best in class latency and security.
📍 Server Placement
No matter which orchestration method you choose, picking the right server location for a group of players is critical in ensuring the best possible ping, and optimal player experience. Learn about different strategies for server placement, and how they impact your players.
Edgegap deploys in the best possible location with available capacity, for fast and low-latency matches.
Server Score
Server score strategy uses Edgegap’s patented methodology, which optimizes placement of servers for each match individually. Performs non-intrusive telemetry to approximate each player’s network proximity to our server locations and choose the server which delivers best:
responsiveness - provides lowest ping for all players on average,
fairness - provides a balanced and fair ping for all players.
Our Matchmaker uses Server Score strategy by default, to ensure best possible experience. To use this strategy with Deploy APIs, input players’ public IPs or geo coordinates in your deploy request.
Unresponsive placement - server is far away, high ping for all players:
Unfair placement - uneven ping, one player is at a disadvantage due to higher latency:
Good placement example - responsive and fair ping for all players:
Geolocation
Alternatively, provide desired server location latitude & longitude coordinates:
⭐ Recommended: Find fastest ping beacon and send its coords, or IP in the user field.
⚙️ Custom: Define regions (with coords.) in your game backend, fetch using custom API.
👉 Simplest for Testing: Define regions (with coords.) hardcoded in game client dev builds.
This strategy is not recommended for Match-Bound orchestration, except for applications with strict regulatory requirements for inter-regional data transfers, or when player IP is unavailable.
Alternatively, let players pick a persistent (always online) server from a list with Server Browser.
Region Lock
Some studios prefer locking stable and predictable locations (e.g. MMOs with Persistence). Consider Server Browser with regional scaling policies and auto-assigned reservations.
This strategy is not recommended for Match-Bound orchestration, except for applications with strict regulatory requirements for inter-regional data transfers, or when player IP is unavailable.
🟢 Connection Quality
Some games (and players) are more sensitive to latency or lag than others. While player reports are a great indicator of incidents or regression bugs at scale, players may lack deep understanding of networking concepts and are quick to assign blame to studios, netcode, or servers.
Root cause of some issues may be hidden from players, so cooperation of studio and hosting provider may be crucial. Edgegap’s priority is always to provide the best possible service.
If you’re receiving numerous player reports, experiencing widespread outages, or repeated issues, please reach out to us immediately through a support ticket in our platform.
Low Latency
Player latency is a combination of latency from transferring data between:
Physical devices - the physical signal travelling across Internet networking topology.
Host to host - resulting from protocol, transport, and security measures.
Process to process - resulting from (un)boxing and processing data in client/server.
Edgegap reduces physical latency by placing servers closer to your players for shorter responses and lower number of network hops. With locations spanning 17 cloud and bare metal providers, you get best-in-class ping for players anywhere in the world.
Server and internet coverage globally (not only with Edgegap) is limited by factors like:
Infrastructure availability - internet connection quality in a given region may not be sufficient.
Natural factors - servers include sensitive components, requiring stability (no earthquakes).
High Availability
Availability of servers in various locations around the world varies over time, shifting many times throughout the day. Edgegap automatically scales up/down locations on demand, considering:
Burst traffic - deployments made within a 15 minute period inform scaling trends.
Resource requirements - total vCPUs demand in each location informs scaling pace.
Provider alternatives - some remote locations have less provider options available.
Provider capacity - some locations may only offer 4 vCPU or 8 vCPU machines.
Quality of Service - some providers offer better network quality across ISPs in the same area.
Studio schedule - special requests for testing and QA, closed betas, or tournaments.
All applications' deploy requests are combined to evaluate demand in each location. All organizations have equal allocation priority by default. Studios have the option to add custom Private Fleets.
Please reach out to us to plan a release, or if you have any requests regarding location availability.
Player Issue Resolution
Player issues may sometimes be caused by server or hosting bugs, but they are often unrelated - consider also issues with cable/wifi connection, Internet Service Provider, backend services, or bugs in client/server low level libraries.
When troubleshooting player reports or incidents, consider factors:
Matchmaking quality - optimize for same-region matches whenever possible:
Matchmaking and Ping Beacons for our recommendations,
🧵 Player Tracing to find server logs related to player reports.
Regional networking and ISP issues:
localized Internet Service Providers (ISPs) may be resolving an incident momentarily,
some regions (e.g. China, Russia) may be restricted due to localized sanctions.
Caching level - without caching, your sessions may be timing out due to slower deployments:
Maximum time to deploy - deployments may fail due to slow and heavy initialization process:
see Safety Guardrails to increase the timeout period.
Server image or integration issues in early iterations of custom build pipelines.
Display deployment IDs in client match history UI to trace player reports when troubleshooting.
🔄 Deployment Lifecycle
Edgegap deployments go through several lifecycle stages, denoted by deployment status.
1. Start a Deployment
A deployment for testing purposes may be started with:
Unreal Engine - Docker Extension or EGIK plugin for Unreal Engine projects.
Unity - hosting quickstart plugin for Unity projects.
Godot - hosting quickstart plugin for Godot projects.
Dashboard Web UI - easy web interface for fast server testing and iteration.
Starting your Deployments manually, pasting URL and ports will not cut it for a live game.
Automate popular game flows for managing sessions and scaling on demand with either:
Shorter Rounds
On-Demand Matches
Skill Rating and/or Custom Rules
Persistent or Rounds
Social Regional Hubs
Auto-Assign and/or Custom Search
Custom Backend:
Migrate Live Games
Save request_id (Deployment ID) and tag Deployments to identify and troubleshoot issues later.
2. Deploying
Once a deployment is started, our system will perform a number of steps in rapid succession:
Telemetry - we’re measuring network responsivity from available data centers to each player,
Deployment - we’re reserving capacity and preparing to start your server container,
Container Boot - we’re starting the container, installing dependencies, and initializing,
Post Processing - we’re adding log storage, monitoring, and finalizing the deployment.
Enable Active Caching in your App Version to deploy servers within seconds.
Too Many Requests 429 - to ensure stability and prevent surprise invoices, we rate limit your organization at 40 req/s. Contact us to plan releases, estimate launch traffic, and prepare for success.
3. Deployment Ready
Once a deployment is Ready, your engine still has work to do. Engines bootstrap subsystems and frameworks, then loads assets, including maps, into memory. This happens after your deployment becomes Ready, and usually takes up to 1 minute depending on your degree of optimization.
Retry player connection a few times, until a pre-defined timeout period elapses, before backing out and starting a new session. Servers typically don't accept new player connections until fully initialized.
Server crash handling depends on your process restart policy. Server state may be lost.
Depending on the version's Active Caching status, you may receive:
🟢 Cache Hit
Caching is enabled. Deployment was faster due to reusing image pre-loaded on this machine.
🟡 Warm Start
Caching is disabled. Deployment was faster due to reusing image downloaded for a previous deployment on the same machine. Enable caching to for consistently fast deployment worldwide.
🔴 Cache Miss
Caching is enabled. Deployment was slower due to a sudden traffic spike before cache propagation completed. Enabling “require cached locations” in your deployment request will prevent this, but may result in more Unprocessable deployments during unexpected traffic spikes.
🔴 Cold Start
Caching is disabled. Deployment was slower, image was downloaded at deployment time. Enable caching for faster deployment.
4. Deployment Error
Your deployment may end up in Unprocessable state at any point in time, for unexpected reasons. This is more likely to happen while testing your integration, or testing new server builds.
You are not charged for Error deployments, which are automatically stopped after 24 hours.
Troubleshooting steps:
Verify Edgegap Service Status with our uptime monitoring page.
Try testing your server container locally using Docker Desktop to rule out Edgegap issues.
When asking for help, include your deployment ID and any useful details so we can investigate promptly!
5. Deployment Stopped
Cloud deployments will be terminated after 24 hours of runtime following our server sanitization policy for infrastructure maintenance, and to prevent racking up unexpected costs when deployment wasn’t shut down properly due to an unexpected bug.
For long-running servers over 24 hours, consider using Private Fleets with Persistence.
Optimize your cost and stop idle deployments early using methods:
App Version Restart Policy - prevent automated restart on shutdown or crashes.
Game Max Duration - allotted time in your Safety Guardrails expired.
Self-Stop via DELETE_URL - deployment stopped itself after players left and match ended.
See Unreal Engine and Unity guides for SDK utilities and easy integration, or use API.
Stop from custom Backend - your custom session orchestration may use Deployments API.
Private Fleets Host running your deployment was deleted through a scheduled action.
👀 Observability
Allow game servers to interoperate with third parties and gain operational insights.
Discoverability
Once Ready, deployment is assigned a URL (fqdn) and an external port for each internal port.
Use deployment tags (up to 40 chars) to easily mark your deployments to find them later.
Websockets (WS) and Secure Websockets (WSS)
To use websocket-based netcode with Edgegap, you have two options:
managed certificate, set up in 1 minute without writing any code:
configure your Apps and Versions to use Websocket (WS) and Enable TLS Upgrade,
use Edgegap URL to connect clients (e.g.
https://5fa53fa00a57.pr.edgegap.net/)
self-managed certificate, if you want to use your own custom domain:
configure your Apps and Versions to use Secure Websocket (WSS),
configure your own TLS certificate flow with a custom DNS record (e.g. on Cloudflare).
Uncaught server exceptions will cause the deployment's container to restart and invalidate TLS security. In such case, stop your server and rematch players to a new deployment. Server state may be lost.
Injected Variables
Game servers often need additional information, such as server IP, internal port values, or other. Injecting read-only environment variables is a reliable cloud-agnostic way to pass parameters.
Get variable values with Unity SDK, Unreal EGIK, or with your runtime's env. variable methods.
Custom Variables
Define up to 20 custom variables for each deployment, each containing up to 4KB of string data.
Avoid using reserved names (below), or your custom variables will be overwritten!
Access important information by reading variables injected to your servers by Edgegap:
Identifiers
ARBITRIUM_REQUEST_ID- e.g.f68e011bfb01.Unique deployment ID, also referred to as request ID. Used to retrieve more information.
Deployment URLs always have format
{ARBITRIUM_REQUEST_ID}.pr.edgegap.net.
ARBITRIUM_PUBLIC_IP- e.g.162.254.141.66.Public IP address of this host, can be used to connect instead of URL.
ARBITRIUM_HOST_ID- e.g.alpha-north-america-70364ef8.Unique identifier of the machine hosting your deployment, shared with other deployments.
ARBITRIUM_DEPLOYMENT_TAGS- e.g.tag1,tag2.Comma-delimited user-defined deployment tags, useful for easy searching and filtering.
ARBITRIUM_PRIVATE_FLEET_ID- e.g.PUBLIC_CLOUD, or fleet ID if hosted on Private Fleets.
Resource Specifications
ARBITRIUM_HOST_IN_PRIVATE_FLEET- e.g.false, indicating if hosted on Private Fleets.ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY- e.g.2300, processor frequency in MHz.ARBITRIUM_DEPLOYMENT_VCPU_UNITS- e.g.256, allocated vCPU units (1024 = 1 vCPU).ARBITRIUM_DEPLOYMENT_MEMORY_MB- e.g.512, allocated RAM in MB (1024 = 1 GB).
Lifecycle Management
ARBITRIUM_DELETE_URL- e.g.https://api.edgegap.com/v1/self/stop/9f511e17/660.Callable from the deployment, deployment will be gracefully stopped.
Requires unique one-time
ARBITRIUM_DELETE_TOKENinAuthorizationheader.
ARBITRIUM_DELETE_TOKEN- e.g.7df4cd933df87084b34ae80d8abde293.ARBITRIUM_CONTEXT_URL- e.g.https://api.edgegap.com/v1/context/9170f5211e17/17.Only callable from the deployment, returns more deployment details.
Requires unique
ARBITRIUM_CONTEXT_TOKENinAuthorizationheader.
ARBITRIUM_CONTEXT_TOKEN- e.g.dfaf50b9333b9ee07b22ed247e4a17e6.
Discoverability
ARBITRIUM_PORT_GAMEPORT_INTERNAL- e.g.7777, internal port for server listener.ARBITRIUM_PORT_GAMEPORT_EXTERNAL- e.g.31504, external port for client connections.External port values are randomized for each deployment for security purposes.
ARBITRIUM_PORT_GAMEPORT_PROTOCOL- e.g.UDP, protocol of your netcode transport.
Examples assume you have named your port gameport (default). Each port adds an additional set of sanitized Port Mapping variables: @Super Port! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .
ARBITRIUM_BEACON_ENABLED- e.g.true, if deploying on Private Fleets with Ping Beacons.ARBITRIUM_HOST_BEACON_PUBLIC_IP- e.g.139.177.198.69, public IP of the closest beacon.ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL- e.g.30199, for ping measurement over UDP.ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL- e.g.30456, for ping measurement over TCP.
Structured Information (JSON as string)
Dashboard Monitoring
Our Dashboard provides utilities to monitor your server scalability and assist with operations.
Analytics
Find analytics dashboards in the sidebar menu under category Server Hosting & Orchestration.
🌟 Upgrade to Pay as You Go tier to unlock detailed server performance metrics and insights:
General Insights: monitor releases with live server count per version + resource usage overview,
CPU Insights: troubleshoot lagging servers due to processor-heavy operations,
Memory Insights: mitigate server restarts due to exceeding allocated memory,
Networking Insights: detect inefficient networking patterns and optimize netcode.
Deployment Map
Find deployment map in your deployment details page on Dashboard.
Preview deployment location, available locations, and estimated player locations on the map:
Deployment Balance Points
Find deployment balance points heatmap in your application details page on Dashboard.
Preview deployment balance points heatmap and filter by Apps and Versions. Balance points are approximate locations with equal network proximity to each player in a given deployment:
Balance point hotspots in strange locations (e.g. Greenland) indicate matchmaking of players far from each other. Learn about 🟢 Connection Quality and Ping Beacons to optimize your matchmaking.
Deployment Logs
Find deployment logs in your deployment details page on Dashboard.
Deployment logs display information about 🔄 Deployment Lifecycle:
Container Logs
Find container logs in your deployment details page on Dashboard.
Inspect your game server’s logs in case of issues, or when debugging:
Once deployment stops, container logs are deleted. Set up third party S3 log storage to save logs.
Container Metrics
Find container metrics in your deployment details page on Dashboard.
Review container metrics (processor, memory, networking) to:
identify common connection issues when 🚨 Troubleshooting,
detect inefficient implementation patterns causing spikes in resource usage,
pinpoint inefficient resource usage in particular scenarios,
verify changes in your server’s resource usage during optimization,
benchmark your server initialization resource consumption and duration.
History metrics display value averages with 1 minute time period, available in Free tier.
🌟 Upgrade to Pay as You Go tier to unlock precise metrics with 1 second time intervals.
Context & Status
Additional deployment information can be retrieved in JSON format:
from inside the deployment (game server), using Deployment Context API,
from outside the deployment (backend / third party), using Deployment Status API.
Too Many Requests 429 - Context and Status APIs are rate limited at 20 req/s per organization. These APIs are intended for use during special operations, not for automated session orchestration.
Use Webhooks for custom session orchestration to avoid rate limiting and ensure scalability.
Filter Deployments
To quickly search amongst all deployments, you can use our dashboard:
Alternatively, let players pick a persistent (always online) server from a list with Server Browser.
List deployments with API and apply filters with backend integrations:
in or nin
[ "7e709a0d8efd", "4ba353100b4b" ]
in or nin
[ "tagA", "tagB" ]
in or nin
[ "my-app", "my-other-app" ]
in or nin
[ "1.0.0", "prod" ]
in or nin
[ "fleet-eu", "fleet-us" ]
ilike
"%-eu%"
in or nin
[ "alpha-north-america-95fab093" ]
ilike
"%north-america%"
Sort results by multiple fields in the order they appear in request:
asc or desc
available_session_sockets
asc or desc
Example filter queries:
Don’t forget to add the Authorization header with your Edgegap API token in the request.
Webhooks
Receive simple HTTP notifications in your game backend for changes in 🔄 Deployment Lifecycle by specifying a webhook URL in your deployment API request. Available for:
On Ready: deployment container started successfully (server starts initializing after this).
On Error: deployment couldn't be started and a 4. Deployment Error occurred.
On Terminate: 5. Deployment Stopped and game server is no longer reachable.
Ready and Error webhooks will never be triggered for the same deployment.
Webhooks are the primary recommended method for custom backend deployment integrations.
Webhooks are not retried, and may be lost if your backend does not process the request due to rate limiting or an error. Fall back to Status API in case you don't receive a webhook within expected time.
🚨 Troubleshooting
When troubleshooting deployments:
verify there are no errors in your Deployment Logs and Container Logs,
run your server locally to rule out integration bugs,
review troubleshooting steps on this page,
reach out to us in Community Discord and include your deployment ID.
Last updated
Was this helpful?