LogoLogo
edgegap.comDashboard
  • 📘Learning Center
    • Getting Started
    • Unreal Engine Games
      • Getting Started - Servers
      • Developer Tools
    • Unity Games
      • Getting Started - Servers
      • Developer Tools
    • Matchmaking
      • Getting Started
      • Matchmaker In-Depth
      • Ping Beacons
    • Advanced Features
      • Apps and Versions
      • Deployments
      • Managed Clusters
  • API Reference
    • Dedicated Servers
    • Integration
    • Matchmaking
    • Peer to Peer
  • Release Notes
    • Archive
  • 📚Documentation
    • Sample Projects
      • Unreal Engine
        • Lyra Sample
        • Top-Down Sample
      • Unity
        • Photon Fusion 2
        • Photon Fusion 1
        • Unity NGO
        • Mirror Pong
        • Mirror
        • Fishnet
        • Photon Bolt
        • Mirror WebGL
        • Fishnet WebGL
      • NuxtJS
      • Ruby On Rails
    • Tools & Integrations
      • Container
        • What is Docker
        • Your First Docker
        • SSH in Your Container
        • External Registries
          • Docker Hub
          • AWS ECR
          • GCP GCR
          • Gitlab registry
      • Deploy from Nakama
      • EOS Lobby Integration
      • Switch From Gamelift
      • Switch From Multiplay
      • Playfab Bridge
    • Container Registry
    • Deployment
      • Endpoint Storage
        • How to Save Logs
        • Upload File to Deployment
      • Webhooks
    • Session
      • How They Work
      • Application Version Configuration
      • Manage Request
      • Selectors Filtering
    • Fleet
      • Fleet Policy
      • Policy Filter
      • Linking Version
      • Fleet's Deployment
    • Relays (P2P)
      • Relay Edgegap API
      • Transport Samples
      • Game Integration
    • Glossary
    • SLA Terms
Powered by GitBook
On this page
  1. 📘Learning Center
  2. Advanced Features

Always Online

Last updated 3 months ago

Was this helpful?

LogoLogo

Connect with Community

  • Discord
  • Linkedin
  • X

Read More

  • Release Notes
  • Blog
  • llms-full.txt

Useful Links

  • edgegap.com
  • Enterprise
  • Legal

© 2025 Edgegap

CtrlK
  • 🚀 Getting Started
  • 🔑 Server Ownership
  • Studio Hosting
  • Crowd Hosting
  • 🥛 Capacity & Scaling
  • Capacity
  • Scalability
  • Scaling Down
  • 🔎 Discoverability
  • 💭 Configuration & State
  • Configuration Management
  • State Management
  • Recovery Objectives
  • 👀 Observability

Was this helpful?

Learn how to enable persistent worlds with 24/7 always online deployments.

If you're new to Edgegap, we recommend starting with:

  • Getting Started - Servers (Unity),

  • Getting Started - Servers (Unreal Engine).

Always Online servers are a requirement for many social games and MMOs with objectives:

  • meet new friends and foster player communities,

  • create and explore an open world with others,

  • engage in epic raid battles involving dozens of players.

Explore strategies to provide the best possible player experience, keep cost under control, and remove player frustration due to outages or rollbacks. Enhance the traditional server model by bringing all the advantages of edge computing packaged for easy use by game developers.

Learn about orchestration, discoverability, and placement of 1. Just-in-Time Deployment.

🚀 Getting Started

To enable uninterrupted 24/7 always online deployments, specify Game Max Duration: -1 when creating your Apps and Versions in the dashboard or with our API. Omitting this parameter will default to a maximum lifetime of 24 hours to prevent unexpected hosting charges.

Test your server scaling and termination process to verify reliability of your cost controls. Server state stored in memory will be lost once the deployment is stopped, see 💭 Configuration & State.

If you need help, please reach out to us over Discord. For live games support see our ticketing system.

🔑 Server Ownership

Explore pros and cons of modern and traditional ownership models with an edge computing twist.

Studio Hosting

Server hosting is typically managed by the studio, covering cost of hosting from game revenue.

👍 Advantages

  • transparent product pricing - cost of hosting is covered by license/subscription of player,

  • strong client/server compatibility with loose coupling of clients, services, and scaling,

  • more resilient to cheating and reverse engineering due to closed source nature of servers.

👎 Disadvantages

  • community modding support is limited to ensure server integrity and stability.

Crowd Hosting

For some games, letting players deploy and fund their own servers is a great option. Contact us to discuss possibilities of exposing hosting (including cost) to players without backend knowledge.

👍 Advantages

  • enhanced modding support through curated list of modded Apps and Versions,

  • improved player feedback loop due to closer collaboration with community,

  • reduced financial risk due to players covering cost of hosting.

👎 Disadvantages

  • more operations for studio - moderating player requests and collecting payments,

  • weaker client/server compatibility due to increased number of modded versions,

  • prone to cheaters due to distributed codebase and possibility of reverse engineering.

🥛 Capacity & Scaling

Learn advanced techniques to optimize server availability, hosting cost, and quality of service.

Capacity

Specifics of your capacity management implementation may differ depending on game engine, netcode, and libraries used. Edgegap doesn't track or manage active player connections after you 1. Start a Deployment to give you absolute control and freedom to implement any design.

Implement capacity management to ensure your servers:

  • maximize cost savings - benchmark and utilize server resources efficiently,

  • provide smooth gameplay - prevent overloading servers with too many concurrent players,

  • prevent bad reviews due to crashes - catch and handle unexpected exceptions.

To ensure efficient server capacity management:

  • release player slots if players matched to game server don't connect within a few seconds,

  • frequently send a minimal heartbeat message from clients to server to keep track of activity,

  • disconnect clients and release player slots if no activity is detected for several seconds,

  • prevent players from being added to servers with full capacity and no available player slots.

Amount of reserved deployment resources can't be changed during runtime. Scale horizontally with new server instances utilizing adjusted application versions requiring more CPU or memory resources.

Scalability

Scaling Always Online servers doesn't require "guesstimating" regional traffic, server cost, configuring and maintaining regional standby, pre-scaling, or configuring multiple Fleets.

Enable caching (CDN) in your 🏷️ App Versions to deploy servers within seconds.

Implement server scaling strategies to ensure your servers:

  • enable large scale hosting while carefully protecting against abuse,

  • minimize wasted server cost due to empty standby servers,

  • prevent long queue times by responding to increased player demand quickly.

Scale with Edgegap Matchmaker or a third party Game Backend, such as Nakama by Heroic Labs:

Integration Key Points

  • scaling authority can be your matchmaker, server browser, or another game service,

  • authority keeps track of running servers and assigns players when capacity available,

  • server notifies authority about 🔄 Deployment Lifecycle and player connections changes,

  • authority periodically cleans up outdated records to prevent invalid assignments.

We strongly recommend scaling based on number of connections instead of physical load (CPU & RAM), since momentary fluctuations in physical load may result in unpredictable availability.

Amount of reserved deployment resources can't be changed during runtime. Scale horizontally with new server instances utilizing adjusted application versions requiring more CPU or memory resources.

Scaling Down

Efficient scale-down policies are key to optimizing cost, but shutting down servers without caution may impact player experience negatively. Consider these factors and test changes before releasing:

Is your detection of player activity / disconnection reliable?

  • Does absence of input reliably indicate player inactivity? Players often use bots, macros, and other techniques to fake activity and maintain active connection to avoid queue times.

  • Are there any actions taken by active players often which are hard to fake?

  • Is using bots or macros an issue or a feature with Crowd Hosting servers?

Is shutting off servers easily and quickly reversible (scale back up)?

  • Once reaching 3. Deployment Ready, your server may require additional time to perform engine initialization and State Management (restoration of state). Do you incur any additional costs for compute or data transfer with game services? Does this wait time impact player experience?

  • Can you hide server loading with a loading scene, mini-game, a lobby, or through other means?

Are players bound to specific server instances or can they migrate easily?

  • How does connecting to a different server influence player's account, purchase history, social experience, progression, inventory, and other gameplay aspects?

  • Review your Recovery Objectives and ensure critical data isn't lost.

  • Implement automated methods or player tools for restoring critical data.

  • Provide human support and communicate with your community about outages and issues.

🔎 Discoverability

To find active servers accepting new players, implement one or more discovery methods:

  • start new servers when sufficient players join matchmaking,

  • add players to backfill existing servers and replace leavers,

  • integrate 🔎 Server Browser to list and join running servers,

  • implement third party lobby and/or matchmaking solutions to discover active servers,

  • add players through a third party friend invite, if server capacity available.

💭 Configuration & State

Integrate services to define initial server requirements and manage player + server state.

Configuration Management

Configuration refers to the initial data passed to your server during deployment:

  • environment-specific injected variables:

    • e.g. client/server version compatibility data,

  • server location, server ports and other server information,

  • matchmaking information or custom deployment variables,

  • third party integration parameters, keys, and secrets.

Configuration is immutable - it's read once after starting your server and doesn't change later on.

State Management

State refers to data describing the result of a series of previous player actions and server events:

  • player connection, player-controlled state changes (e.g. Pawn),

  • changes related to objects contained in the level/scene (e.g. Actor, Game Object),

  • changes related to game mode, game state, or game scene information.

State data changes frequently. Clients aren't aware of all changes and receive updates with a small delay.

Perform frequent state backups to prevent data loss in case of unexpected client or server issues:

  • asynchronously in real time using a third party service, e.g. Nakama by Heroic Labs,

  • on client/server startup or shutdown, as deserialized state files in cloud object storage.

Game objects typically designate an owner who controls them, this can be either server or a player.

Server Owned Objects

Server owned objects can be manipulated only by server. Connected players have limited read access to server owned objects. Server owned objects are usually not shared with other servers.

Server owned objects can be loaded by a replacement server in case a unexpected server crash. Use deployment URL, deployment ID, or a custom tag to uniquely identify your server.

Player Owned Objects

Player owned objects can be manipulated both by players and server. Assigning ownership of persistent objects to players makes migration to other servers easier later on.

Back up state of player owned objects on player device or a game backend between play sessions.

Prevent cheating by validating changes with server authority. Authority and ownership can be separate.

Recovery Objectives

In case of issues, some categories of data may be more sensitive to data loss, for example:

  • account, subscription, purchase, and microtransaction data - critical,

  • progression, achievement, leaderboards, and inventory data - important,

  • cheat detection, moderation, performance, and error tracking data - important,

  • player behavior, social, chat data - low importance.

Implement restoring purchases from independent transaction history for best player experience.

We highly recommend discussing the following amongst management and production:

  • categories of data handled in your game clients and servers,

  • importance and sensitivity of each category for your business and players,

  • Recovery Point Objective (RPO) - acceptable amount of data loss before serious harm occurs,

  • Recovery Time Objective (RTO) - acceptable amount of downtime before serious harm occurs.

Unexpected crash of server will cause your server to restart automatically. Server state may be lost.

👀 Observability

Long running (always online) servers bring new observability challenges, specifically detecting anomalies in monitoring, logging, and bug tracking.

We strongly recommend implementing alerts for server restarts to gain more operational visibility.

Since our Endpoint Storage log integration only transfers logs after 5. Deployment Stopped, integrating additional logging and bug tracking (such as Sentry) helps troubleshoot partial failures.

See also 🟢 Connection Quality (Ping Beacons) and 🟢 Connection Quality (Deployments).

Reach out for bare metal hosting to optimize cost savings for games with predictable player traffic.