AccelByte Extend: Custom Backend Logic, Hosted and Operated for You

Every game reaches a point where the backend needs to do something it does not do by default.

For example, things like skill-based matchmaking, connecting rewards to player progress, using an API to blend external player data with your own logic, or getting multiple backend systems to talk to each other. 

These game-specific requirements are common, but they still need somewhere to live and run. If you host it yourself, you also take on the work of managing the infrastructure behind them including deployments, monitoring, scaling, and maintenance on top of everything else your team is already doing.

AccelByte Extend gives that custom logic a place to live without adding more infrastructure to your plate. Whether your game runs on AccelByte or other platforms, Extend lets you write logic your game needs in the language you already use while we handle running, scaling, and operating it.

The rest of this blog explains how Extend works, the types of Extend apps available, and how studios use them to run custom backend logic alongside their game services.

What Extend is

Extend is a hosted customization framework. It is not a way to modify source code, and it is not limited to teams whose entire stack runs on AccelByte Gaming Services.

Extend apps can call any external API, integrate with third-party services, and act as a bridge layer between AccelByte systems and whatever else is in your game's backend. Studios running a mixed stack, some services on AGS, others elsewhere can use Extend to write the logic that connects them, without running that logic on their own.

For teams using AccelByte already, Extend provides defined hook points where custom logic replaces or extends specific default behaviors. For teams integrating AGS with external tools and services, Extend provides the hosted runtime to run that integration code reliably, with observability included.

In both cases, the model is the same: you write the logic, AccelByte operates it.

Practical details for devs: Extend apps are Docker containers deployed to a dedicated VM per namespace. Supported languages are Go, C#, Java, and Python. Apps are managed through the Admin Portal and the extend-helper-cli command-line tool.

The three types of Extend apps

Extend gives you three distinct tools, each built for a different kind of customization. Understanding which one fits a given situation is where the real leverage is.

Choosing the right Extend app type depends on what you want your backend logic to do. The diagram below provides a quick way to think about it.

Let’s go through each one and see how it works in practice.

Extend Override: replace default AGS behavior with your own

AccelByte Gaming Services has defined points where its default behavior can be substituted with custom logic. Extend Override is how that works. When an Override app is registered, AGS calls your gRPC server at that specific hook point instead of running default function. Everything else continues as normal. Only that function changes.

How it works technically:

• An Override app is a gRPC server. AGS acts as the gRPC client and calls your defined methods instead of its own. App templates exist for every supported override point and include authentication, authorization, and observability instrumentation out of the box. You implement the logic. The template handles the rest.

When to use it: When specific AGS behavior needs to be different for your game, not added to, but replaced. 

Concrete use cases:

1. Matchmaking is the most common starting point. Default matchmaking logic handles general cases well. A competitive game with skill tiers, regional constraints, or party size rules needs matchmaking that understands those variables. An Override app lets you implement exactly that logic and register it against a match pool. AccelByte continues handling session management, server allocation, and surrounding infrastructure. Your Override decides how players are grouped.
2. Loot box and reward probability is another strong fit. If economy rules need to live server-side, adjusting drop rates based on player history, purchase behavior, or seasonal conditions, an Override app owns that calculation without exposing it to client-side manipulation.
3. Challenge goal assignment, session lifecycle hooks, rotating shop item logic, and chat filtering all follow the same pattern. Any point where the AGS default exists but does not match what the game needs is a candidate.

Extend Service Extension: build new backend services, hosted by AccelByte

Not every requirement is about replacing something that already exists. Sometimes a game needs a service that does not exist anywhere in the current stack, a custom API backed by logic and data specific to the game that clients or game servers can call.

Extend Service Extension builds those services. You write the logic, AccelByte hosts it, scales it, and makes it accessible with a public URL and auto-generated API documentation.

How it works technically:

• A Service Extension uses a gRPC Server and gRPC Gateway stack. You define endpoints in a Protobuf file, implement the gRPC server methods, and the template handles the rest at build time: generating the REST layer, producing an OpenAPI 2.0 specification, and wiring up authentication. The service has a public URL and Swagger documentation accessible from the Admin Portal.

When to use it: When you need a net-new service your game can call, whether that service talks exclusively to AGS systems, exclusively to external systems, or to both.

Concrete use cases:

1. A custom MMR and skill rating calculator. After each match, the game server calls a Service Extension endpoint. The extension runs the calculation using your algorithm, writes updated ratings back to AGS player stats, and returns the new value. The logic lives entirely server-side, in a service the team controls, callable from anywhere.
2. Guild or clan systems with custom progression rules. AGS has foundational guild support, but if the guild system has specific rules around contribution tracking, tier advancement, or resource management, a Service Extension builds that as a proper hosted API the client calls directly.
3. External data integration. If player data, entitlements, or content lives in a system outside AGS, a partner platform, an analytics service, a legacy database, a Service Extension can fetch, transform, and expose that data in a format the game needs, with AccelByte handling the hosting and uptime.
4. EOS Voice session syncing is a real shipped example. An Extend Service Extension listens for AccelByte session events and keeps Epic Online Services Voice rooms aligned with session membership, a custom bridge service between two separate backend systems, running on Extend without any self-managed infrastructure.

Extend Event Handler: react to AGS events asynchronously

Some logic does not need to intercept a flow. It needs to respond to something that already happened. Extend Event Handler listens for events emitted by AGS and runs custom logic when they fire. This is asynchronous. The event happens, AGS emits it, the handler processes it on its own timeline without blocking the original operation.

How it works technically:

• Event Handler apps subscribe to specific AGS event types. When an event fires, AGS delivers it via a message queue. The handler processes it and can call back into any AGS service using the Extend SDK. The template includes idempotency handling guidance, which is relevant in event-driven systems where duplicate delivery is possible.

When to use it: When logic should happen because of an event, not during one.

Concrete use cases:

1. Season-end reward distribution. When a season closes, AGS emits an event. The handler evaluates player standings and grants entitlements to qualifying players automatically. No manual trigger, no scheduled job to maintain.
2. Login-based rewards. When a player logs in for the first time, hits a login milestone, or logs in on a specific date, an Event Handler catches that and executes the reward logic without any game client involvement.
3. Stats propagation in a ranked system. When player MMR updates after a match, a Stats Listener Event Handler picks up the event, evaluates ranking thresholds, and updates tier assignments or triggers promotions. This is how complex connected systems, full ranked matchmaking suites, for example link multiple services without coupling them directly to each other.

How the Three App Types Work Together End-to-End

The real power of Extend becomes clear when you combine all three app types. Here is how a competitive ranked season might work end-to-end with every step handled:

Integrating with third-party services

Extend apps are not limited to talking to AccelByte systems. Any Extend app can make outbound calls to external APIs, third-party platforms, or services outside the AccelByte ecosystem.

This makes Extend useful for studios running mixed stacks. If your game uses AGS for identity and matchmaking but a separate service for analytics, economy, or voice, Extend is where you write the integration logic that connects them and where that logic runs reliably, with hosting and observability included.

Published examples include:

1. EOS Voice syncing, where an Extend app mirrors AccelByte session state into Epic Online Services Voice rooms in real time, handling token generation and membership management automatically.
2. Easy Anti-Cheat handling, where an Extend app listens for EAC events from the client and dedicated server, applies ban logic, sends reports, and keeps ban state consistent across the backend.
3. External player data ingestion, where a Service Extension fetches data from outside systems and exposes it in a format AGS services or game clients can consume directly.

The open-source Extend Apps Directory also explicitly includes patterns that studios not on AccelByte can fork, adapt, and run on their own infrastructure. The templates and architecture are not locked to AGS deployments.

Hosting, scaling, and observability

Once deployed, AccelByte operates Extend apps. This covers several things teams would otherwise manage themselves. Each namespace gets a dedicated virtual machine for its Extend apps. VMs are not shared between namespaces, which means isolation is built into the architecture. Extend handles horizontal auto-scaling as player count and request volume grow.

Observability is provided through Grafana Cloud, integrated directly into the platform. Every Extend app gets dashboards for metrics, logs, and distributed traces out of the box. Logs are collected automatically from stdout. The Grafana Cloud interface is accessible from the Extend app details page in the Admin Portal.

For developers, this means standard observability tooling without the setup work. For studio leadership, it means the team has visibility into how custom services are performing without building a monitoring stack separately.

The Extend Apps Directory

AccelByte maintains an open-source directory of Extend apps covering the patterns that come up most often across game studios, available publicly on GitHub. No login required. It is also linked from within the AGS Admin Portal once Extend is enabled.

Available apps include custom matchmaking functions, MMR calculator services, rotating shop item handlers, reward event processors, guild progression services, and third-party integrations. Each is a functional starting point. Fork it, modify the logic for your game, and deploy. The infrastructure, authentication, observability, and deployment pipeline are already handled by the template.

For studios evaluating Extend, the directory is the fastest way to understand what custom logic looks like in practice. For studios actively building, it is a way to start from a working implementation rather than a blank repository.

Languages and tooling

Extend apps are Docker containers. Development and deployment follow a consistent workflow across app types and languages.

Supported languages: Go, C#, Java, Python. TypeScript support is in development.

extend-helper-cli handles the operational workflow from the command line: authenticating against AccelByte's container registry, building and uploading Docker images, creating and configuring apps, managing environment variables and secrets.

App templates exist for each app type and language. They include gRPC boilerplate, authentication and authorization interceptors, observability instrumentation, and Makefile commands for building and running locally. Starting point is always a working app. Development begins by modifying logic, not assembling scaffolding.

Local development and testing is supported. Apps can run locally and be exposed via a tunnel service for testing against a live AGS environment before deployment.

Accelerate Development with AI and MCP Servers

Once your backend is programmable, the next bottleneck is usually speed: how quickly you can build custom logic and wire services together.

AccelByte Extend is designed to work well with AI-assisted development.

Internally, we combine AccelByte CodeGen with MCP (Model Context Protocol) servers to expose structured knowledge about our APIs, SDK architecture, and service relationships. This gives AI the context it needs to generate working integrations instead of generic code.

This approach helps in two ways.

1. Speed up how developers build Extend apps themselves. With structured SDK knowledge exposed through MCP, AI assistants can help generate the repetitive wiring involved in backend logic: calling the right services, shaping requests, and connecting systems correctly.

2. Accelerate platform development. Using CodeGen and AI-assisted workflows, our engineers can generate the full SDK foundation for new engines in days instead of weeks.

In practice, this means you can describe something like a daily login reward, matchmaking rule, or progression update and quickly scaffold the Extend app that implements it.

You still define the logic. Extend simply hosts & runs it, while AI helps you build faster.

Who should be looking at Extend

Extend is relevant when game-specific backend logic needs to exist somewhere, and the cost of building and operating that infrastructure independently is a meaningful concern for the team.

A game with straightforward requirements such as standard matchmaking, cloud saves, and a leaderboard does not need Extend. Core AGS services handle that well without custom logic.

The signal that Extend is worth evaluating usually looks like one of these:

• Your team is already building custom backend services and hosting them independently. Extend is a way to have that infrastructure operated for you instead.
• Your game has economy, matchmaking, or progression rules too specific to express through configuration alone. Those rules belong server-side, in a system your team controls.
• Your stack uses multiple backend systems and you need logic that connects them. Extend is where that bridge code runs without self-managed servers.
• Your LiveOps team needs automated event-driven behavior that currently requires manual intervention or a separate tool to manage.

For studios already on AGS, Extend is the path from using AccelByte's systems to having AccelByte run your systems as well. For studios with a mixed stack, it is the hosted runtime for the logic that connects everything.

Where to go from here

• Read the Extend documentation and architecture overview at docs.accelbyte.io
• Browse or clone a working reference app from the Extend Apps Directory
• Review the pricing and usage limits pages before planning your architecture
• Talk to us about your specific use case (especially if you are migrating)