Most dedicated game-server tutorials show you how to deploy a container. Fewer show you how to connect that server to player identity, matchmaking, and console entitlements without stitching together four separate vendors. AccelByte Gaming Services (AGS), built by a team that previously shipped online infrastructure for Fortnite, Xbox Live, and EA Origin, bundles both halves: a backend platform for identity, matchmaking, and live-ops, plus AccelByte Multiplayer Servers (AMS) for provisioning and scaling the actual dedicated game-server fleets. This tutorial walks through setting up an AGS project from zero, wiring in the Unity SDK, packaging a dedicated server for AMS, and configuring autoscaling, with a working project structure and a realistic cost model at the end. This guide fits alongside our broader cloud computing coverage for teams evaluating backend platforms for multiplayer titles in 2026.
What AGS and AMS Actually Cover
AccelByte splits its platform into two layers that solve different problems. AGS is the backend layer: player accounts, entitlements, matchmaking queues, leaderboards, and live-ops tooling, delivered as managed APIs you call from your game client. AMS is the infrastructure layer underneath it: a dedicated-server orchestrator that provisions, deploys, scales, and routes game-server fleets across both cloud virtual machines and bare metal, according to AccelByte’s own platform documentation. You can use AGS without AMS if you already host your own servers, or use AMS standalone if you only need server orchestration and already have your own backend, but most studios adopt both together because that combination is what AccelByte’s pricing and packaging are built around.
What sets AGS apart from backend platforms like PlayFab or Unity Gaming Services is console-identity support built directly into the SDK layer: AccelByte advertises native integrations for PlayStation Network, Xbox, and Nintendo Switch identity, which matters for any cross-platform title that would otherwise need a separate identity-federation vendor for console certification. AGS also ships an extension layer called AGS Extend, which lets you override or add custom backend behavior without forking the platform or managing the infrastructure that custom code runs on, a middle ground between a fully managed black box and running your own backend from scratch.
On the billing side, AGS Public Cloud charges by Peak Concurrent Users per day (PCCU) rather than total registered accounts, calculated from the maximum number of players simultaneously connected to and interacting with AGS APIs during a 24-hour window. Published public-cloud pricing starts at roughly $0.0124 per PCCU per day once you exceed the free tier, according to AccelByte’s current pricing page, with the rate stepping down as PCCU volume grows. A new account gets a 90-day free trial with no credit card required, covering up to 30 CCU during that development window, which is enough headroom to complete every step in this tutorial without billing concerns.
AGS: The Backend Layer
Think of AGS as the parts of a live-service game that have nothing to do with where a match actually runs: player accounts and entitlements, matchmaking queues and rule sets, leaderboards and seasonal resets, and in-game economy tracking. These are the services your game client talks to constantly, win or lose, connected to a match or sitting in a menu. AccelByte packages this layer into named bundles (Foundations, Online, and Multiplayer are referenced in AccelByte’s own comparison materials), which studios can adopt individually depending on how much of the stack they want managed versus self-built.
AMS: The Server Orchestration Layer
AMS, by contrast, only cares about the lifecycle of the actual dedicated-server process: provisioning a container, placing it on suitable cloud or bare-metal capacity, scaling the fleet up or down with demand, and routing a connecting player to a specific instance. It has no concept of player identity or matchmaking rules on its own; those live in AGS and simply hand AMS a request to fulfill. This separation is deliberate and mirrors the architecture used by most mature live-service backends: identity and matchmaking are stateful, long-lived services, while dedicated-server instances are ephemeral and disposable by design.
Prerequisites
- A free AccelByte account (90-day trial, no credit card, up to 30 CCU per AccelByte’s current pricing page)
- Unity 2022 LTS or newer, or Unreal Engine 5.x (this tutorial uses Unity; Unreal steps follow the same pattern through the Unreal SDK)
- Docker Engine 27.x or newer for packaging the dedicated server build
- Node.js 20.x or newer if you plan to script the AMS deployment flow outside the dashboard
- Basic familiarity with REST APIs and OAuth2-style client credentials
- curl and jq for testing API calls from the command line
- A GitHub account, since the Unity SDK installs via Unity Package Manager using a GitHub package URL
- At least 60–90 minutes for the full walkthrough, including account provisioning and your first AMS deployment
Step 1: Create an AGS Project and Namespace
Sign up at AccelByte’s developer portal and create a new project. Every AGS resource (player accounts, matchmaking rules, server builds) nests under a project-level namespace, so name it something stable; renaming a namespace later means updating every SDK config and API call that references it. Once created, note your Base URL, Client ID, and Client Secret from the project’s Admin Portal under IAM (Identity and Access Management) settings. These three values authenticate every API call in the rest of this tutorial.
Treat the Client Secret the same way you would a database root password: store it in a secrets manager, never commit it to a public repository, and scope separate credentials for development versus production environments from the start rather than retrofitting that separation later.
Step 2: Install the Unity SDK
AGS ships a native Unity SDK installed through Unity Package Manager using a GitHub package URL rather than the standard Unity Asset Store flow. Open Window → Package Manager → “+” → “Add package from git URL” and paste the AccelByte Unity SDK repository URL from your project’s documentation page. Once imported, add the AGS configuration asset to your project and populate it with the Base URL, Client ID, and namespace from Step 1:
// AccelByteSDKConfig.asset (populated via Unity Inspector, shown here as reference)
{
"Namespace": "my-shooter-game",
"BaseUrl": "https://my-shooter-game.prod.gamingservices.accelbyte.io",
"ClientId": "YOUR_CLIENT_ID",
"RedirectUri": "myshootergame://callback"
}Initialize the SDK at game startup before any other AGS call:
using AccelByte.Core;
using AccelByte.Api;
void Start()
{
AccelBytePlugin.Initialize();
var user = AccelBytePlugin.GetUser();
user.LoginWithDeviceId(result =>
{
if (!result.IsError)
Debug.Log("Logged in: " + result.Value.userId);
else
Debug.LogError("Login failed: " + result.Error.Message);
});
}Device-ID login is the fastest way to confirm connectivity during development. Swap it for email/password, Steam, PSN, Xbox, or Switch login once you move toward a real build; AGS’s console-identity SDKs follow the same pattern with different login method calls.
Step 3: Authenticate a Test Player via the REST API
Before wiring up the full client, confirm your credentials work directly against the API. This also gives you a reusable pattern for any backend service (a matchmaking bot, a CI test harness) that needs to call AGS without going through the game client:
curl -X POST "https://my-shooter-game.prod.gamingservices.accelbyte.io/iam/v3/oauth/token"
-H "Content-Type: application/x-www-form-urlencoded"
-u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET"
-d "grant_type=client_credentials" | jq .## Example response (trimmed)
{
"access_token": "eyJhbGciOi...",
"token_type": "Bearer",
"expires_in": 3600,
"namespace": "my-shooter-game"
}Store the access token and reuse it for the duration of its 3600-second lifetime rather than requesting a new one on every call; AGS, like most OAuth2-based platforms, rate-limits token endpoints separately from resource endpoints, and hammering the token endpoint is a common and avoidable source of throttling during load testing.
Step 4: Containerize Your Dedicated Game Server for AMS
AMS deploys containerized dedicated servers, so package your server build into a Docker image regardless of engine. A minimal Dockerfile for a Unity headless Linux server build looks like this:
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y
libc6-dev libstdc++6 ca-certificates &&
rm -rf /var/lib/apt/lists/*
WORKDIR /game
COPY ./ServerBuild ./ServerBuild
# AMS injects the assigned port via environment variable at runtime
ENV AMS_SERVER_PORT=7777
EXPOSE 7777/udp
CMD ["./ServerBuild/MyShooterServer.x86_64", "-batchmode", "-nographics"]Build and smoke-test the image locally before registering it with AMS:
docker build -t my-shooter-server:v1 .
docker run --rm -p 7777:7777/udp my-shooter-server:v1Confirm the process starts cleanly and listens on the expected port before pushing anywhere. A container that crashes on startup is far faster to debug on your own machine than after AMS has already scheduled it to a remote node.
Step 5: Register the Build and Create a Deployment
Push your image to a container registry AMS can pull from, then register a build and deployment through the Admin Portal or API. The deployment definition specifies resource limits, port mappings, and scaling rules:
curl -X POST "https://my-shooter-game.prod.gamingservices.accelbyte.io/ams/v1/namespaces/my-shooter-game/deployments"
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
-H "Content-Type: application/json"
-d '{
"name": "shooter-deployment-v1",
"image": "registry.example.com/my-shooter-server:v1",
"port": { "number": 7777, "protocol": "UDP" },
"resources": { "cpu": "1", "memory": "1Gi" },
"minCount": 1,
"maxCount": 10
}'The minCount and maxCount fields define AMS’s autoscaling floor and ceiling for this deployment. A minCount of 1 keeps a warm instance ready so the first match of the day doesn’t pay a cold-start latency penalty; a sensible maxCount prevents a matchmaking bug from scaling your fleet (and your bill) unbounded.
Step 6: Request a Server Session From the Client
With a deployment live, your Unity client (or a matchmaking service acting on its behalf) requests a server allocation and receives back connection details:
using AccelByte.Api;
AccelBytePlugin.GetAMS().RequestServerSession("shooter-deployment-v1", result =>
{
if (!result.IsError)
{
string ip = result.Value.ServerIp;
int port = result.Value.ServerPort;
ConnectToGameServer(ip, port);
}
else
{
Debug.LogError("AMS allocation failed: " + result.Error.Message);
}
});As with most container-orchestrated server platforms, the port returned here is assigned dynamically per instance and will not match the internal port your Dockerfile exposes. Always read connection details from the API response rather than hardcoding a port in client logic; this is the single most common first-deployment bug across every orchestrated game-server platform, not just AMS.
Step 7: Wire Up Matchmaking
AGS includes a matchmaking service that groups players into sessions based on rules you define, then hands the formed match to AMS for server allocation. Define a basic matchmaking rule set:
{
"matchRuleName": "quickplay-4v4",
"allianceRule": {
"minNumber": 4,
"maxNumber": 4,
"playerMinNumber": 1,
"playerMaxNumber": 1
},
"matchingRule": [
{ "attribute": "skill_rating", "criteria": "distance", "reference": 150 }
]
}Once players join a matchmaking ticket, AGS forms a match according to this rule set and, when configured to integrate with AMS, automatically triggers a server allocation for the formed match rather than requiring your client to call AMS separately. This keeps your matchmaking and server-allocation logic in one managed pipeline instead of two systems you have to keep in sync yourself.
Step 8: Add Console Identity (PSN, Xbox, Switch)
If your title ships cross-platform, AGS’s native console-identity SDKs remove the need for a separate identity-federation vendor. The login call pattern mirrors the device-ID example from Step 2, swapping in the platform-specific login method:
// PlayStation Network login (conceptually identical for Xbox and Switch)
user.LoginWithPlatform(PlatformType.PS5, platformToken, result =>
{
if (!result.IsError)
Debug.Log("PSN login success: " + result.Value.userId);
});Each console platform still requires its own first-party certification and credential setup outside of AGS (a PSN client ID from Sony, an Xbox title ID from Microsoft), but AGS removes the need to run a separate token-exchange service between those platforms and your own backend.
Step 9: Configure Health Checks and Graceful Shutdown
A server that crashes mid-match without reporting its status leaves players stranded and AMS unaware the instance needs replacing. Implement a basic liveness signal inside your server process and a graceful shutdown handler that drains the current match before terminating:
# Pseudocode inside your game server process
on_sigterm():
notify_ams_draining()
wait_for_current_match_to_end(max_seconds=120)
exit(0)AMS sends a termination signal before reclaiming an instance during scale-down events; a server that ignores this and dies instantly mid-match produces a worse player experience than one that finishes the current match first. Budget a drain window that matches your game’s typical match length, not an arbitrary default.
Step 10: Set Up Live-Ops Tooling
AGS’s live-ops layer covers leaderboards, in-game economy, and event scheduling through the same project namespace you’ve already configured. Create a basic leaderboard definition through the Admin Portal or API:
curl -X POST "https://my-shooter-game.prod.gamingservices.accelbyte.io/leaderboard/v1/namespaces/my-shooter-game/leaderboards"
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"
-H "Content-Type: application/json"
-d '{
"leaderboardCode": "weekly-kills",
"name": "Weekly Kill Count",
"timeFrame": "WEEKLY"
}'Submitting scores from the client afterward is a single authenticated call, and the leaderboard automatically resets on the configured time frame without any additional cron job or scheduled Lambda on your side, which is one less piece of infrastructure a small team has to own compared with building leaderboards from scratch on raw cloud primitives.
Step 11: Load Test Your Deployment
Before pointing real players at the setup, simulate concurrent server allocations to confirm your minCount/maxCount scaling rules behave as expected:
for i in $(seq 1 15); do
curl -s -X POST "https://my-shooter-game.prod.gamingservices.accelbyte.io/ams/v1/namespaces/my-shooter-game/deployments/shooter-deployment-v1/sessions"
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" &
done
waitWatch the Admin Portal’s deployment dashboard during this test for allocation latency and any failed sessions. A healthy configuration should scale smoothly between your floor and ceiling without allocation failures; failures under moderate concurrency usually point to a resource request (CPU or memory) set too high for the node pool AMS is scheduling against.
Step 12: Tear Down Test Sessions and Monitor Cost
Because AGS Public Cloud bills by daily PCCU, idle test sessions that never terminate inflate your peak figure for that day even without real player activity. Explicitly close test sessions after each load test:
curl -X DELETE "https://my-shooter-game.prod.gamingservices.accelbyte.io/ams/v1/namespaces/my-shooter-game/sessions/SESSION_ID"
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"Use AccelByte’s pricing calculator to sanity-check your projected PCCU volume against the published per-PCCU-per-day rate before committing to a production launch date, rather than discovering your actual bill only after the first full billing cycle.
Step 13: Automate Deployment Updates With CI/CD
Once the manual flow is proven, wire image builds and AMS deployment updates into your existing CI pipeline:
- name: Build and update AMS deployment
run: |
docker build -t registry.example.com/my-shooter-server:${{ github.sha }} .
docker push registry.example.com/my-shooter-server:${{ github.sha }}
curl -X PATCH "$AMS_BASE_URL/ams/v1/namespaces/my-shooter-game/deployments/shooter-deployment-v1"
-H "Authorization: Bearer $AMS_TOKEN"
-H "Content-Type: application/json"
-d "{"image": "registry.example.com/my-shooter-server:${{ github.sha }}"}"
env:
AMS_TOKEN: ${{ secrets.AMS_TOKEN }}
AMS_BASE_URL: ${{ secrets.AMS_BASE_URL }}Tie deployment version labels to commit SHAs rather than hand-typed tags, the same discipline that matters on any orchestrated game-server platform, so that a rollback during an incident is a one-line revert rather than a guessing game about which hand-labeled build was actually stable in production.
The Unreal Engine Path: What Changes
Everything from Step 2 onward follows the same pattern for studios building on Unreal Engine 5, with the Unity Package Manager install swapped for AccelByte’s Unreal plugin, added through the Unreal Marketplace or by cloning the SDK plugin repository directly into your project’s Plugins folder. The configuration values (Base URL, Client ID, namespace) are identical; only the code that consumes them changes syntax. A login call in Unreal’s C++ API looks like this:
#include "Api/AccelByteUserApi.h"
void AMyPlayerController::LoginWithDeviceId()
{
FRegistry::User.LoginWithDeviceId(
FVoidHandler::CreateLambda([]() {
UE_LOG(LogTemp, Log, TEXT("AGS login success"));
}),
FErrorHandler::CreateLambda([](int32 ErrorCode, const FString& ErrorMessage) {
UE_LOG(LogTemp, Error, TEXT("AGS login failed: %s"), *ErrorMessage);
})
);
}AccelByte’s documentation notes that the September 2026 release notes for the AGS platform reference Unreal Engine 28.5.1 and OSS (Online Subsystem) 0.13.9 as current supported component versions, which is worth checking against your own project’s Unreal version before starting integration, since Online Subsystem compatibility windows shift with each Unreal release. The AMS deployment and container-packaging steps from Step 4 and Step 5 require no changes at all between Unity and Unreal; both engines produce a headless Linux server binary that gets wrapped in the same style of Dockerfile.
Securing API Credentials and Player Data
Every call shown in this tutorial authenticates with either a Client ID/Secret pair or a bearer token derived from it, and both deserve the same operational discipline you would apply to any production credential. Never embed a Client Secret inside a shipped game client; the OAuth2 client-credentials flow used in Step 3 is meant for server-to-server calls (your matchmaking bot, your CI pipeline, your backend reconciliation job), not for code that ships to a player’s device. Game clients should authenticate players through the SDK’s user-login flows from Step 2, which exchange a player’s own credentials for a short-lived, player-scoped token rather than exposing your project’s root-level secret.
Separate your development and production namespaces fully, including separate Client IDs, so a bug in a load-testing script can never touch live player accounts or billing. If your studio runs a bug bounty or external security review, scope it explicitly to exclude destructive testing against your production AGS namespace, and use a dedicated staging namespace instead, the same precaution any team running a managed backend platform should take regardless of vendor.
AGS vs. Unity Gaming Services vs. PlayFab: Where It Fits
AccelByte, Unity Gaming Services, and PlayFab all bundle backend services with some form of server orchestration, but they differ on console-identity depth, extensibility, and pricing structure. AGS leads on native PSN/Xbox/Switch identity support built into the core SDK rather than requiring a bolt-on vendor, which studios shipping simultaneously across consoles and PC tend to value most. Teams already comparing Unity Gaming Services against PlayFab and Beamable should weigh AGS as a fourth option specifically when console parity and white-label backend extensibility (via AGS Extend) outweigh deeper native integration with one specific game engine’s broader toolchain. If your studio only needs the dedicated-server orchestration piece without the full backend suite, it is also worth comparing AMS against AWS GameLift Servers and Agones on Kubernetes, both of which focus purely on server orchestration and leave backend services as a separate build-your-own layer.
| Factor | AccelByte AGS + AMS | Unity Gaming Services | PlayFab |
|---|---|---|---|
| Console identity | Native PSN, Xbox, Switch in core SDK | Via Unity’s multiplatform tooling | Requires additional integration work |
| Public cloud free tier | 90 days, up to 30 CCU, no card required | Free tier varies by service tier | Limited free evaluation quota |
| Billing unit | Daily Peak Concurrent Users (PCCU) | Varies by service (CCU, MAU-based) | VM-hours, egress, storage meters |
| Extensibility | AGS Extend — custom backend logic, managed infra | Cloud Code functions | CloudScript functions |
| Best fit | Cross-platform console titles wanting one vendor | Unity-first teams already in Unity’s ecosystem | Teams standardized on Azure/Microsoft stack |
Cost Modeling: Public Cloud PCCU Pricing in Practice
Run realistic numbers before committing to a launch budget. At a published rate of roughly $0.0124 per PCCU per day, a title averaging a daily peak of 500 concurrent players costs approximately $6.20 per day, or around $186 per month, in AGS Public Cloud usage alone, before any AMS compute cost for the actual dedicated-server fleet. That compute cost scales with your deployment’s minCount/maxCount settings from Step 5 and the underlying VM or bare-metal rate for the region you deploy to.
| Daily peak CCU | Estimated AGS cost/day | Estimated AGS cost/month | Notes |
|---|---|---|---|
| 30 (free tier ceiling) | $0 | $0 | Covered by 90-day trial, no card required |
| 500 | ≈ $6.20 | ≈ $186 | Small live-service title, early growth stage |
| 5,000 | ≈ $62 | ≈ $1,860 | Rate may step down at this volume per AccelByte’s tiered pricing |
Studios expecting to exceed roughly 2,000 PCCU sustained should contact AccelByte for private-cloud quoting, since published private-cloud packages start at approximately $1,500 per month for the Foundations tier, $2,500 for Online, and $3,500 for Complete, and typically include negotiated commercial terms rather than the flat public-cloud per-PCCU rate. Always confirm current numbers against AccelByte’s live pricing calculator before finalizing a budget, since usage-based SaaS pricing structures shift with volume commitments and contract terms.
Remember that the figures above cover AGS backend usage only, not AMS compute. Add your underlying VM or bare-metal hourly rate, multiplied by the expected number of concurrent server instances during peak hours, to get a complete monthly estimate; AccelByte’s own pricing calculator lets you model both the AGS PCCU meter and an AMS compute estimate side by side rather than treating them as two unrelated bills. Validating both halves together, instead of just the headline PCCU rate, is what separates a realistic launch budget from a surprise invoice in month two.
5 Common Pitfalls When Setting Up AGS and AMS
1. Hardcoding the AMS-assigned server port in client code. Like every orchestrated game-server platform, AMS assigns the external port dynamically per deployment instance. Always read it from the RequestServerSession response rather than assuming it matches your Dockerfile’s internal port.
2. Letting test sessions run unterminated. Because AGS bills by daily peak CCU, forgotten load-test sessions inflate your billed peak for that day even without real players. Script explicit session teardown into every test harness.
3. Setting maxCount too high without a hard ceiling check elsewhere. A matchmaking bug that keeps requesting new sessions can scale a deployment all the way to its configured ceiling before anyone notices. Pair maxCount with an alert on sustained high allocation rates.
4. Skipping graceful shutdown handling. A server that doesn’t listen for AMS’s termination signal and drain its current match produces disconnects during routine scale-down events, not just during real incidents. Build the drain handler from Step 9 before your first production deployment, not after the first player complaint.
5. Reusing one set of API credentials across development and production namespaces. AGS supports separate projects and credentials per environment specifically so a bug in a development script can’t touch production player data or billing. Set this separation up in Step 1 rather than retrofitting it after a scare.
Advanced Tips for Production Deployments
Once the basic setup is stable, a few patterns pay off at scale. Use AGS Extend to move latency-sensitive custom logic (anti-cheat validation, a custom matchmaking tiebreaker) closer to the platform rather than round-tripping through your own separately hosted backend, since Extend runs inside AccelByte’s managed infrastructure. Tag AMS deployment versions with the same commit SHA your CI pipeline uses for the backend, so a post-incident timeline can correlate a backend change with a server-fleet change without cross-referencing two separate version schemes. For titles with a predictable daily player curve (an evening peak, a weekend spike), set minCount to cover your typical off-peak floor and rely on maxCount headroom for the predictable peak window, rather than running a flat minimum around the clock that overpays during quiet hours. Finally, if you adopt console identity from Step 8, build your QA pass to specifically test token-expiry and re-authentication flows on each platform separately, since PSN, Xbox, and Switch each handle session refresh slightly differently at the first-party level, independent of anything AGS itself controls.
Complete Working Project: Putting It All Together
Here is how the pieces from this tutorial combine into one coherent flow for a small production setup: a player logs in through the Unity SDK (device ID in development, console identity in production), joins a matchmaking ticket defined by your quickplay rule set, AGS forms a match and triggers an AMS session allocation, the client receives connection details and connects directly to the assigned dedicated server, and the server reports health and drains gracefully on scale-down. CI builds and pushes new server images on every merge, tagged by commit SHA, and patches the live AMS deployment automatically. A periodic job reconciles active AMS sessions against your own match database to catch anything orphaned.
my-shooter-project/
├── client/
│ ├── Assets/Scripts/AGSLogin.cs # device ID + console identity login
│ ├── Assets/Scripts/Matchmaking.cs # ticket join + match-found callback
│ └── Assets/Scripts/ServerConnect.cs # reads IP/port from AMS session
├── server/
│ ├── Dockerfile
│ ├── ServerBuild/ # headless Linux build output
│ └── shutdown_handler.sh # SIGTERM drain logic
├── backend/
│ ├── leaderboard-config.json
│ └── matchmaking-rules.json
├── .github/workflows/
│ └── deploy.yml # CI: build, push, patch AMS deployment
└── reconciler/
└── session-cleanup.js # orphaned-session cleanup jobThis structure scales from a solo prototype to a small studio team without a major rewrite. What changes as you grow is how much of the private-cloud tier you negotiate, how sophisticated your matchmaking rule sets become, and how much custom logic you push into AGS Extend versus your own separately hosted services.
Troubleshooting: 8+ Common Issues and Fixes
Login call returns an authentication error immediately. Confirm the Base URL in your SDK config matches your project’s exact environment URL (development vs. production namespaces use different base URLs) and that the Client ID matches the same environment.
Token request succeeds but resource calls return 401. The access token likely expired (3600-second default lifetime) or you’re reusing a token across namespaces. Implement token refresh logic rather than caching a single token indefinitely.
AMS deployment stuck in a pending state. Check the resource request (CPU/memory) in your deployment definition against available node capacity in the Admin Portal; an oversized request for the target node pool is the most common cause.
Client connects to the server but receives no data. Verify the protocol declared in your deployment definition (UDP vs. TCP) matches what your game actually sends over the wire, and confirm the Dockerfile’s EXPOSE directive matches as well.
Matchmaking tickets never resolve into a match. Review your matchmaking rule set’s allianceRule and matchingRule fields for a configuration that is mathematically impossible to satisfy (for example, a skill-distance criterion too tight for your current player pool size during testing).
Unexpectedly high daily PCCU bill. Audit for unterminated test or QA sessions using the session-list endpoint, cross-referenced against your own match database, the same reconciliation pattern covered in the Complete Working Project section above.
Console login fails only on one platform. Confirm first-party credentials (PSN client ID, Xbox title ID) are correctly registered with that platform’s developer portal independently of AGS; AGS passes through platform tokens but does not replace first-party certification requirements.
CI pipeline fails to patch the live AMS deployment. The stored AMS token in your CI secrets has likely expired or been rotated in the Admin Portal without updating the corresponding CI secret. Regenerate and update it, and consider scripting an automated rotation reminder.
Leaderboard scores not resetting on schedule. Confirm the timeFrame field in your leaderboard definition matches your intended reset cadence; a leaderboard created with an “ALL_TIME” frame will never reset automatically regardless of how your event schedule is configured elsewhere.
Unreal build fails to pick up the AGS plugin after an engine upgrade. Cross-check the Online Subsystem and Unreal Engine version your AGS SDK release targets (AccelByte’s September 2026 release notes list Unreal Engine 28.5.1 and OSS 0.13.9 as current supported versions) against your own project’s engine version before assuming the plugin itself is broken; a mismatch here is a far more common cause than an actual SDK defect.
Frequently Asked Questions
Is AccelByte Gaming Services free to start with?
Yes. AGS Public Cloud offers a 90-day free trial with no credit card required, covering up to 30 CCU during that development window, according to AccelByte’s current pricing page. That is enough to complete every step in this tutorial before adding billing details.
Do I need to use AMS if I already host my own game servers?
No. AGS’s backend services (identity, matchmaking, leaderboards) can be used independently of AMS if you already operate your own server infrastructure. You call AGS APIs for backend functionality and keep your own hosting pipeline for the actual dedicated servers.
Which game engines does AGS support?
AccelByte ships native SDKs for Unity and Unreal Engine, with console-identity support for PlayStation Network, Xbox, and Nintendo Switch built into those SDKs. Custom engines can integrate directly against the REST APIs shown in this tutorial.
How does AGS pricing compare to PlayFab or Unity Gaming Services?
AGS bills public-cloud usage by daily Peak Concurrent Users rather than VM-hours or monthly active users, which changes how costs scale with your player base’s actual concurrency pattern rather than total registered accounts. Compare your specific usage profile against each platform’s calculator rather than assuming one billing model is universally cheaper.
Can I run AMS on my own bare-metal infrastructure instead of AccelByte’s cloud?
AMS supports deployment targets across both cloud VMs and bare metal according to AccelByte’s platform documentation. Check current documentation for the exact private-infrastructure integration options available, since managed-platform capabilities for bring-your-own-hardware scenarios evolve over time.
What happens if an AMS deployment fails mid-match?
Your matchmaking and client logic should detect the failure through session status checks and trigger a new allocation, migrating connected players to the replacement instance. Building this failover path, rather than assuming deployments never fail, is a requirement for any production setup on any orchestrated game-server platform.
Does AGS Extend require me to manage servers for my custom backend code?
No. AGS Extend is designed specifically so you can override or add backend behavior without forking the platform or managing the infrastructure that custom code runs on, according to AccelByte’s own product documentation. You write the logic; AccelByte’s managed infrastructure runs it.
How quickly can I move from this tutorial’s setup to a real production launch?
Technically, the setup from Steps 1 through 13 is production-capable once you swap device-ID login for real authentication and load-test your actual game logic rather than a placeholder server. The realistic timeline depends more on your own game’s readiness and console certification timelines (for PSN, Xbox, or Switch identity) than on any AGS-specific setup bottleneck.
What if my project outgrows the free 30 CCU trial before I’m ready to pay?
Reach out to AccelByte’s sales team before the trial window closes; most managed-platform vendors, AccelByte included, can extend or adjust trial terms for a project showing genuine development progress rather than forcing a hard cutoff. Budget time to have your PCCU cost model from this tutorial ready to discuss, since it demonstrates you understand your own projected usage rather than asking for an open-ended extension.
Can I migrate an existing game already live on PlayFab or GameLift to AGS and AMS?
Migration is possible but not automatic; player accounts, entitlements, and match history live in vendor-specific data models that require an explicit export-and-import pass rather than a drop-in swap. Treat a backend migration as its own project with its own testing phase, run in parallel against a staging AGS namespace, before cutting production traffic over. Studios evaluating this path should also budget time to re-test console certification flows, since PSN, Xbox, and Switch each require their own validation pass against any new identity backend before a live cutover.