Modules

The Rudder backend is a kernel: players, authentication, wallets, counters, storage, resources and releases. Game-design features ship as modules on top of it.

A module package is a manifest.json (see Module manifest) plus a module.wasm binary built from Go (the only supported module language for now). The backend stores each published version, installs it per project and environment, and runs its functions in an embedded WebAssembly runtime (see Functions runtime).

Built-in packages (items, inventory, reward, remote_config, leaderboards, quests, store, battlepass) are first-party marketplace versions, described in First-party modules. A project can pin a marketplace version (updates flow in) or eject it (a project-owned copy that marketplace updates no longer touch).

Calling a module from the game

Game clients call functions with trigger client through POST /sdk/v1/modules/{module}/{fn}. Use a generated module client: rudder client generate reads the manifests of the installed modules and writes typed arguments, results and error codes.

import { modules } from './rudder.modules';

const { entries } = await modules(client).leaderboards.top({ slug: 'weekly_high_score', limit: 10 });

var m = new RudderModules(client);
var top = await m.Leaderboards.TopAsync(new LeaderboardsTopArgs { Slug = "weekly_high_score", Limit = 10 });

The player response is { result } only. Every client call carries an Idempotency-Key, so the SDKs can retry network errors, 5xx and 409 conflict without running the function twice. When a module fails a call on purpose, the response is HTTP 422 with the common error body { error, code, requestId }; the SDKs raise RudderModuleError (TypeScript) or RudderModuleException (C#), and the generated client lists the codes each function can return. A crash inside the module returns 500 and a timeout returns 504, both without details.

Game servers call functions with trigger admin through POST /game/v1/modules/{module}/{fn} with the environment’s admin key (X-API-Key). There is no server SDK; call the HTTP API directly.

Building and publishing

Installing first-party modules and configuring them in the dashboard is open to every project. Publishing your own modules, eject and dry run are in early access: they are available only to allowlisted publisher accounts. Write to hello@rudder.build to request access.

The rudder CLI scaffolds, builds and publishes modules. Builds run in a Docker image:

rudder module init --slug my_module
rudder module build
rudder module dry-run --fn hello --args '{"name":"Ada"}'
rudder module publish
rudder module install --slug my_module --version 0.1.0

Server commands read --url, --token, --project and --environment (or RUDDER_URL, RUDDER_TOKEN, RUDDER_PROJECT, RUDDER_ENVIRONMENT). dry-run always runs in staging and never commits.