Remote config · versioned delivery · live operations

Change runtime settings without turning every balance tweak into a client patch.

Crux stores immutable config bundles per environment. Upload a version, activate it deliberately, and let your game server or authenticated player session fetch only the active bundle. The control plane stays separate from your executable release.

Create a free Live Config project → Remote-config architecture guide
Release contract 
upload: balance-42.json
  ↓ stored, NOT live
activate: balance-42
  ↓ one active per environment
GET /configs/active/bundle
  ↓ game/server receives active bytes
rollback: activate an older version
Verify before you integrate

Inspect the config lifecycle before trusting it with live balance.

The public OpenAPI contract separates upload, activation, metadata reads and active-bundle delivery. That separation is intentional: a successful upload cannot silently change the live version.

Live API status

A live check of the hosted API right now. No made-up uptime percentage and no hidden demo environment.

Check current status

Public API contract

The hosted HTTP surface is documented as OpenAPI. Inspect the wire format before choosing an SDK or writing an adapter.

Open the spec

MIT client SDKs

The JavaScript, Godot, Unity, and Roblox client SDK source is public. The hosted backend itself remains a managed proprietary service.

Inspect the SDK source

Documented exit path

Read what is exportable today and the written commitment for advance notice plus an export window if the hosted service winds down.

Read the exit guarantee

Remote config for live games

See what belongs in remote config, what should stay in code, and how to keep rollout reversible.

Read the implementation guide
01

Immutable versions

A version label cannot be overwritten in place. Upload a new version when the bytes change, so history remains inspectable and rollback stays explicit.

02

Explicit activation

Upload and activation are separate actions. Exactly one version is active for an environment; activating another version moves the pointer.

03

Runtime fetch

Trusted servers or authenticated player sessions can download the active bundle. Crux Runtime is not required; your compute can live anywhere.

Good fit

Use it for values your runtime needs to change independently of a binary release.

  • balance constants and loot weights
  • event schedules and rotations
  • server rules and environment-specific settings
  • feature parameters where your game owns the evaluation logic
Not a full LiveOps suite

No audiences, experiments or analytics engine.

Crux does not currently assign players to experiment cohorts, calculate statistical significance, schedule audience rules, or replace an analytics platform. If those are the job, use a dedicated LiveOps system and keep Crux for the config-delivery primitive.

Compare broader LiveOps platforms
First useful test

Publish one harmless value, then roll it back.

Create a project, prove the API from your actual game/server process, upload a small JSON bundle, activate it, fetch the active bytes, then activate the previous version. That exercises the whole control loop before you put economy or balance behind it.

Ship the first config version → Inspect API docs