Deployments
Last updated
Was this helpful?
Last updated
Was this helpful?
Learn about deployments and their lifecycle - concepts and best practices for deeper understanding.
Edgegap Deployment service starts new servers on demand, only once your players need them, using cloud-native approach, and treating server instances as cattle rather than pets - replacing faulty instances entirely instead of nursing each one manually. To fully understand the pros and cons, let’s compare with other orchestration methods.
Your orchestration choice will impact your devops cost, server cost, and scalability.
Most games don’t fit perfectly in a box. Reach out to us over Community Discord for friendly advice.
Golden standard for modern studios providing the easiest integration with best cost efficiency.
👍 Advantages
lowest hosting cost, scaling capacity to meet demand minute by minute,
lowest devops cost due to region-less hosting, Edgegap automates 99% of tasks,
lowest ping time due to 615+ sites in Edgegap’s global server pool,
fastest scale up (burst-ability) in case of unexpected traffic spike (~3s to deploy),
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
competitive, latency-sensitive games - netcode optimization can only get you so far,
First Person Shooters, Fighting Games, VR & XR (virtual and extended reality), …
match-based games - with an upper limit on match duration,
MOBA, Battle Royale, Cooperative Shooters, Sports Games, ARPGs & Dungeon Crawlers, …
Edgegap automatically scales all 615+ server locations up/down based on player activity in each region. Prepare for success - seamlessly scale to 14 million concurrent users in 60 minutes.
Traditional model for live games seeking easy and cost efficient alternative to their current hosting.
👍 Advantages
highest standard of security and player cheating prevention (server authority),
familiar and easy to understand, traditional approach for battle-scarred veterans,
allows long-running servers past 24 hours of lifetime (frequent backups recommended),
👎 Disadvantages
higher hosting cost, each region requires 1+ unused standby servers (burst capacity),
higher devops cost, operations and maintenance duplicated per region,
varying ping time depending on player location, usually up to 15 server server locations,
unexpected server crash may impact multiple matches, if hosted on the same machine,
🧩 Best Suited For
asynchronous multiplayer games - server crashes have minimal impact on player experience:
race against ghosts, loot enemy base, timer-based social building/farming games, …
latency-tolerant games - when server authoritative real-time physics aren’t required:
MMOs, some Cooperative Games, TCGs/CCGs, Turn-Based Strategies, …
See our Smart Fleets for regional standby alternative to maintain a low-tide capacity.
See Managed Clusters for self-hosting your microservices and backend services on Edgegap.
Shift development efforts from dedicated servers to relay netcode for non-competitive game designs.
👍 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,
🧩 Best Suited For
cooperative and casual games - when cheating doesn’t take away from fun or break the game,
Open-World Sandbox Games, Kids Games, Exploration Games, Adventures, …
indie games seeking funding - cost-effective option to produce a publisher demo.
See our Distributed Relays for a peer to peer service with best in class latency and security.
No matter which orchestration method you choose, picking the right server location for each player (or a group of players) is crucial in ensuring the best possible ping, and optimal player experience. Learn about different strategies for server placement, and how they impact your players.
Your server placement strategy will impact your players’ experience, retention, and your game reviews.
Edgegap deploys in the best possible location with available capacity, for fast and low-latency matches.
See Deployment Balance Points to analyze server placement in real time, at scale.
Server score strategy uses Edgegap’s patented placement methodology, which optimizes placement of servers for each match individually. Our system performs non-intrusive telemetry to approximate each player’s network proximity to our server locations, and chooses the server which aims for:
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 server score strategy with our Deploy and Session APIs, list players’ public IPs in geo_ip_list.
Unresponsive placement - server is far away, high ping for all players:
Unfair placement - uneven ping, one player is at a disadvantage:
Good placement example - responsive and fair ping for all players:
This strategy is especially effective for hosting a group of players far away from each other (North America vs. Europe, or West coast vs. East coast), frequently the case with pre-made lobbies.
Alternatively, provide players' latitude & longitude coordinates or coordinates of a preferred server location instead of leveraging automated telemetry. This approach requires additional client-side geo-lookup implementation, fully relying on game developer’s solution.
Geolocation strategy is not recommended except for enterprise applications with strict regulatory requirements for inter-regional data transfers, or when player IP is unavailable.
As the last resort, servers may be placed based on a crudely generalized region parameter, either:
automatically chosen for the player, based on their metadata (player account database), or
selected by the player during matchmaking, allowing placement with high client-server latency.
Using only Region Lock strategy alone is not recommended as it may result in poor network performance.
Some games (and some 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 using through a support ticket in our platform.
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 across 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 due to factors like:
infrastructure availability - internet connection quality in a given region may not be sufficient,
natural factors - highly complex server racks require mostly stable environment.
Availability of servers in various locations around the world will vary over time, changing multiple times throughout the day. Edgegap automatically scales up/down locations on demand, considering:
burst traffic - deployments made within a 15 minute period,
vCPU requirements - more vCPU per deployment increases overall demand for specific location,
provider offering - some remote locations have less provider options available,
machine availability - some locations may only offer 4 vCPU or 8 vCPU machines,
studio requests for testing, quality assurance, early access, closed betas, or tournaments.
All applications' deploy requests are combined to assess location demand. All organizations have equal allocation priority by default, with the possibility to add private server pools for enterprise customers requiring specific hardware or locations.
Please reach out to us to plan a release, or if you have any requests regarding location availability.
Player issues may be rooted in server bugs or provider incidents, but may also arise from third parties such as local ISPs, game services, bugs in low level libraries, infrastructure providers, or other sources.
When troubleshooting player reports or incidents, consider factors:
matchmaking quality - players should be close to each other (same region) for 📍 Server Placement to yield best results:
see Getting Started and Ping Beacons for our recommendations,
regional 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 - Edgegap will prioritize fast deployments in cached locations:
maximum time to deploy - deployments may fail due to slow and heavy initialization process:
see version parameters to increase the timeout period,
server image or integration issues - see 🚨 Troubleshooting.
Display deployment IDs in client match history UI to trace players when troubleshooting.
Notify users about widespread bugs, temporary issues, and outages to mitigate negative sentiment.
Edgegap deployments go through several lifecycle stages, denoted by deployment status.
A deployment for testing purposes may be started with:
Getting Started - Servers - plugin for Unity projects,
Getting Started - Servers - plugin for Unreal Engine projects,
Dashboard Web UI - easy to use web interface for testing server integration.
A deployment for live production environment should be started with:
Deploy API - server-to-server customized match integration (custom matchmaking),
Session API - server-to-server customized session integration (custom group matchmaking),
Smart Fleet Policy - keep a minimum number of 2. Regional Standby servers running.
Save request_id (Deployment ID) and tag Deployments to identify and troubleshoot them later.
When testing with Deploy API, you may override default Dockerfile CMD with custom command.
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.
Too Many Requests 429 - to ensure stability and prevent surprise invoices, we rate limit your organization at 40 deployments/second. Contact us to plan releases, estimate launch traffic, and prepare for success.
Your container is fully initialized and your server is starting up now. For a few seconds/minute, your server may be still initializing and may not respond to player requests until your game engine (or custom runtime) is fully ready to accept player connections.
Once the deployment is Ready, retry player connection until successful, or until pre-defined client timeout.
Your deployment may end up in Error 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 deployments in Error, which are automatically stopped after 24 hours.
Troubleshooting steps:
Verify Edgegap Service Status by visiting our uptime monitoring page.
Try running 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!
We never stop your servers without your directive, to prevent impacting your players’ experience negatively. Your deployment may be stopped for these reasons:
Self-Stop via DELETE_URL - deployment stopped itself after players left and match ended,
Stop from your backend - your server stopped this deployment using Deploy API,
only triggered with Seat or Match sessions, not available with Matchmaker In-Depth.
Once a deployment is stopped, we trigger graceful termination by sending SIGTERM signal to your main process, allowing a short termination period. Once expired, a SIGKILL signal is sent to stop deployment.
Allow game servers to interoperate with third parties and gain operational insights.
Once Ready, deployment is assigned a URL (fqdn) and an external port for each internal port.
Use deployment tags to easily mark your deployments and Filter Deployments.
Outbound traffic (to clients or backend) from your game servers is never blocked or filtered.
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.
Game servers often need additional information, such as server IP, internal port values, or other.
Get variable values using GetEnvironmentVariable in C# or GetEnvironmentVariable in C++.
To make accessing important information more convenient, we inject environment variables:
ARBITRIUM_REQUEST_ID - Unique deployment ID, also referred to as request ID. Used to retrieve more information. Example - f68e011bfb01.
Deployment URLs always have format {ARBITRIUM_REQUEST_ID}.pr.edgegap.net.
ARBITRIUM_PUBLIC_IP - Public IP address of this deployment. Example - 162.254.141.66.
ARBITRIUM_CONTEXT_URL - Only callable from the deployment, returns deployment details.
Example - https://api.edgegap.com/v1/context/9170f5211e17/17.
Requires ARBITRIUM_CONTEXT_TOKEN in Authorization header.
ARBITRIUM_CONTEXT_TOKEN - Example - dfaf50b9333b9ee07b22ed247e4a17e6.
ARBITRIUM_DEPLOYMENT_TAGS - Comma-delimited tags. Example - tag1,tag2
ARBITRIUM_PORT_GAMEPORT_INTERNAL - Server listens on internal port. Example - 7777.
ARBITRIUM_PORT_GAMEPORT_EXTERNAL - Clients connect to external port. Example - 31504.
External port values are randomized for each deployment for security purposes.
ARBITRIUM_PORT_GAMEPORT_PROTOCOL - Protocol of your netcode transport. Example - UDP.
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_DELETE_URL - Callable from the deployment, deployment will be gracefully stopped.
Example value - https://api.edgegap.com/v1/self/stop/9f511e17/660.
Requires ARBITRIUM_DELETE_TOKEN in Authorization header.
ARBITRIUM_DELETE_TOKEN - Example - 7df4cd933df87084b34ae80d8abde293.
Environment variables are stored as stringified JSONs, parse them using an SDK or a custom method.
Define up to 20 custom variables for each deployment, each containing up to 4KB of string data.
Avoid using reserved names above to prevent overwriting existing variables with custom variables.
Our Dashboard provides utilities to monitor your server scalability and assist with operations.
Find deployment map in your deployment details page on Dashboard.
Preview deployment location, available locations, and estimated player locations on the map:
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.
Find deployment logs in your deployment details page on Dashboard.
Deployment logs display information about 🔄 Deployment Lifecycle:
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 will be deleted. Set up third party S3 log storage for persistent logs.
Find container metrics in your deployment details page on Dashboard.
Review container metrics to:
identify common connection issues (see 🚨 Troubleshooting),
pinpoint your game server bottlenecks (CPU / memory / networking) over time,
verify changes in your server’s resource usage during optimization,
benchmark your server initialization resource consumption and duration.
Contact us prior to your release for Advanced Monitoring to support large scale releases.
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.
Context API (only from deployment) requires Context API token, while Status API uses your Edgegap token.
Too Many Requests 429 - we rate limit your organization at 10 req/second for Context and Status API endpoints. Use Injected Environment Variables and Webhooks for a scalable solution.
To quickly search amongst all deployments, you can use our dashboard:
List deployments with API and apply filters with backend integrations. One filter maximum per field:
status - 🔄 Deployment Lifecycle
eq (equals) or neq (not equals) + string "ready" or "error"
request_id - 👀 Observability
eq (equals) + string request_id (deployment ID)
in (in array) or nin (not in array) + string array [ "7e709a0d8efd","4ba353100b4b" ]
tags - Discoverability
eq (equals) + string tag
in (in array) or nin (not in array) + string array [ "tagA", "tagB" ]
created_at - #1-start-a-deployment
eq (equals) or lte (lower than or equal) or gte (greater than or equal) + string ISO 8601 date
application - Apps and Versions
eq (equals) or neq (not equals) + string name
in (in array) or nin (not in array) + string array [ "my-app", "my-other-app" ]
version - Apps and Versions
eq (equals) or neq (not equals) + string version
in (in array) or nin (not in array) + string array [ "1.0.0", "prod" ]
is_joinable_by_session - Sessions and Seats (custom matchmaking)
eq (equals) + boolean true or false
available_session_sockets - Sessions and Seats (custom matchmaking)
eq (equals) or neq (not equals) or lt (lower than) or lte (lower than or equal) or gt (greater than) or gte (greater than or equal) + integer sockets
List of returned deployments can be sorted by multiple fields in the order they appear in request:
created_at - #1-start-a-deployment
asc (ascending - oldest first) or desc (descending - newest first)
available_session_sockets - Sessions and Seats (custom matchmaking)
asc (ascending - full first) or desc (descending - empty first)
Example filter queries:
Don’t forget to add the Authorization header with your Edgegap API token in the request.
If you need to receive a simple HTTP notification when a deployment is Ready or in Error, you can specify a webhook URL in your deployment API request.
Webhooks are not retried, so if your backend does not process the request due to rate limiting or an error, the webhook may be lost. Use webhooks only for non-critical use cases or debugging purposes.
For reliable deployment observers, implement jittered exponential retry or poll Deployment Status API.
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.
See Player Issue Resolution for our recommendations on navigating player community feedback.
Using region selection as a secondary matchmaking pre-filter in combination with another strategy is a viable option. See or use filters field in our APIs for custom integrations.
see to learn how to find server logs related to player reports,
to delay initialization steps until absolutely necessary,
- secure and scalable managed service for game clients,
Enable caching (CDN) in your to deploy servers within seconds.
Game Max Duration - the allocated time in your has expired,
Empty Time To Live - no players have connected within the defined period:
See your App version's variables and Matchmaker in addition.
If you’re using Photon Fusion 2 netcode, please ensure that your server is passing the deployment public IP, external port and the roomCode on the server, and the same room code in the client in the “NeworkRunner.StartGame” parameter StartGameArgs. Deployment ID (e.g. b63e6003b19f) is a great choice as it’s globally unique and easily accessible to client by Matchmaker assignment and to the .
To allow players to join games in progress, consider using or Sessions.
If you're new to Edgegap, we recommend starting with:
Getting Started - Servers (Unity),
Getting Started - Servers (Unreal Engine).
If you need help, please reach out to us over Discord. For live games support see our ticketing system.
If you need help, please reach out to us over Discord. For live games support see our ticketing system.
