Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

rbx-cli

Unified Roblox Open Cloud CLI. One binary, one install, every tool as a subcommand. The command is rbx, short because you type it all day.

This site is a rendering of the docs/ directory of the rbx-forge/rbx-cli repository. Every page is the file the repository already serves, built by CI on every push to main, so the site and the repository cannot disagree. The “Suggest an edit” link at the top right of each page opens the exact file it came from.

Two tools, one backbone

The command surface looks broad because it is two products that happen to share a spine. The spine is the environment model: one rbxplace.toml maps env names to universes and places, and every command resolves --env through it.

Declarative, Terraform for Roblox. init, env, apikey, place, meta, config, shop. You write the desired state into a TOML file you commit, and the tool reconciles Roblox to match it. Diffable, reviewable, safe to run on every push, idempotent by construction.

Operational, kubectl for Roblox. servers, analytics, ban, restart, data, memorystore, message. These act on state that only exists while the game is running, and no TOML file can describe it. Banning a player is a consequence of what happened in your game last night, not a checked-in intention.

Comparable tools have the first pillar. Mantle never had the second, and nothing else does either: you are otherwise clicking through the Creator Hub or writing your own Open Cloud scripts. The second pillar is the difference between deploying a game and running one, and it is why the surface is wide on purpose rather than by accretion.

Every command

CommandWhat it does
initCreate the group, universe and places, and write them into rbxplace.toml
importAdopt a universe that already exists: every config and lockfile, from what is live
envRead rbxplace.toml: list envs, print one id, generate a module for game code
apikeyDeclare Open Cloud keys and their scopes, create and rotate them
doctorProve the loaded key works, with one real read rather than a syntax check
checkEvery configured tool’s check in one pass, one exit code. status is the same engine for a human
placePlace files: upload, download, promote between envs, roll back
metaUniverse and place metadata: name, icon, thumbnails, devices, visibility
configThe live in-experience config, with revisions and rollback
shopGame passes, badges and developer products, with typed Luau codegen
serversLive. Servers up now, how the stopped ones ended, and what a crashed one logged
analyticsLive. Players, retention, revenue per payer. CSV for charting elsewhere
banLive. Inspect and change player restrictions
restartLive. Forecast and launch a rolling server restart
dataLive. Read, overwrite, copy and recover one data store entry
memorystoreLive. Write cache values servers read through MemoryStoreService
messageLive. Push a MessagingService message to every running server
adsLive. Launch and steer ad campaigns. Spends money, reads no results
probeLive. A raw authenticated request to any Open Cloud path
openLaunch Studio at a place, by name or by id
downloadFetch a Roblox asset by id
completionsShell completions that read your rbxplace.toml at TAB time

Everything marked Live acts on a running game and shares one safety model: dry run by default, --apply to write, --env all refused. That model, and the keys it wants, are on Live operations.

Install

Add it to your project’s rokit.toml, then run rokit install. Pin the version you want from the releases page:

[tools]
rbx = "rbx-forge/rbx-cli"

Or let Rokit write that entry for you. Pass the alias explicitly, or you get an rbx-cli command instead of rbx:

rokit add rbx-forge/rbx-cli --alias rbx

The precompiled binaries attached to every release need no Rust toolchain. Building from source does, at the MSRV declared in the workspace manifest.

Where to start

Two ways in, depending on whether the experience exists yet:

  • Nothing on Roblox yet. rbx init creates the group, universe and places, and writes the rbxplace.toml that everything else reads.
  • A universe that already exists. rbx import adopts it: every config and lockfile written from what is live, in one command.

Both paths converge on the same three pages. rbx env explains the rbxplace.toml they produce and how --env resolves through it, rbx apikey manages the Open Cloud keys declaratively, and rbx doctor proves those keys work with one real read rather than a syntax check.

From there:

  • Putting it in CI. rbx check runs every configured tool’s check in one pass with one aggregated exit code. That page is also where rbx status, the same engine for a human rather than a pipeline, is documented.
  • Shipping a build. rbx place uploads, downloads, promotes between envs and rolls back to a past version.
  • Everything that is not the place file. rbx meta for universe and place metadata, rbx config for in-experience live configs, rbx shop for passes, badges and developer products with typed Luau codegen.
  • Acting on a running game. Live operations is the entry point and the safety model: dry run by default, --apply to write, --env all refused.
  • More than one person on the repository. Working in a team is the lockfile conflict procedure. Worth reading before you need it, because a badly resolved rbxshop.lock.toml creates a second paid game pass that this tool cannot delete.

Not on this site

Documentation about the repository rather than the tool stays in the repository: README for the full command table and the stability policy, ARCHITECTURE.md for the crate layout, CONTRIBUTING.md for setup and what makes a PR mergeable, CHANGELOG.md for what changed in a release, and SECURITY.md for where vulnerability reports go, which is never the public tracker.

rbx-cli is a community tool under MPL-2.0. It is not affiliated with, endorsed by, or sponsored by Roblox Corporation.