Show the envs defined in rbxplace.toml. Pass the global --env <name> to show a single one.

rbx env list
rbx env list --env prod       # just this env
rbx env list --names          # env names only, one per line
rbx env list --place-names    # place names only, one per line
rbx env list --json           # one JSON document on stdout

Output mirrors the file so it maps back onto what you’d edit:

rbxplace.toml
owner = group 1234567

[dev]
universe_id  = 9876543210
places.lobby = 987654321
places.main  = 123456789012345

[prod]  confirm
universe_id = 9876543211
owner       = user 42
places.main = 234567890123456

confirm next to the env header means that env has confirm = true and will prompt before write operations. A per-env owner line appears only when [<env>.owner] overrides the top-level [owner].

--json

One JSON document on stdout, nothing else. Diagnostics — the unknown-key warning in particular — stay on stderr, so the document parses even when the file has something wrong with it.

{
  "schema_version": 1,
  "places_file": "rbxplace.toml",
  "owner": { "type": "group", "id": 1234567 },
  "envs": [
    {
      "name": "dev",
      "universe_id": 9876543210,
      "confirm": false,
      "codegen": true,
      "places": { "lobby": 987654321, "main": 123456789012345 }
    },
    {
      "name": "prod",
      "universe_id": 9876543211,
      "env": "production",
      "owner": { "type": "user", "id": 42 },
      "confirm": true,
      "codegen": true,
      "places": { "main": 234567890123456 }
    }
  ]
}

envs[].owner is the override as the file spells it, never the resolved value, so .envs[].owner // .owner reproduces the fallback and “inherited” stays distinguishable from “overridden”. Optional fields are omitted rather than emitted as null, so has("owner") is a usable test.

A file with no envs is an empty envs array and exit 0, matching --names rather than the human listing, which errors. Both are read by scripts; the error is for the person who asked to see the file.

rbx env list --json | jq -r '.envs[] | select(.confirm) | .name'   # envs that prompt
rbx env list --json | jq -r '.envs[].places | keys[]' | sort -u    # every place name

The two name listings

Two listings meant to be read by something other than a person. Both write one bare value per line to stdout, nothing else, no colors, and both exit 0 on a file that simply has nothing to list:

rbx env list --names          # dev
                              # prod
rbx env list --place-names    # lobby
                              # main

These are a supported surface, not debug output. The shell completions generated by rbx completions call exactly these two commands, and so can your scripts — the format is one value per line and will not grow columns, headers or color.

--place-names answers across every env by default, deduplicated: a place name is a role, and main defined in three envs is one candidate, not three. Narrow it with the global --env:

rbx env list --place-names --env prod

The union is the default because the question is usually asked before an env has been chosen — a completion for --place cannot wait for --env to be typed. The cost is that in a file where envs hold genuinely different places, the unnarrowed list offers names that the env you eventually pick does not have; the command you run then says so.

Both listings fail with an empty stdout when rbxplace.toml is missing or does not parse. The diagnostic goes to stderr, so 2>/dev/null is all a caller needs to get silence instead of an error.

Print a single value. The value goes to stdout bare — no label, no color, no trailing decoration — so it can be captured directly.

UNIVERSE=$(rbx env get universe-id --env prod)
PLACE=$(rbx env get place-id --env prod --place lobby)

rbx env get owner-id                       # top-level [owner], no --env needed
rbx env get universe-id --env all          # one "<env><TAB><value>" line per env

The file’s own snake_case spellings are accepted as aliases (universe_id, place_id, …), so you can type what you see in the TOML.

Without --place, place-id follows the same defaulting rule as every other subcommand: main if it exists, otherwise the only entry, otherwise an error listing the available names.

With --env all, output is tab-separated so it pipes cleanly:

rbx env get universe-id --env all | cut -f2

Missing envs, missing places, and a missing [owner] are errors (exit code 1) with the available options listed on stderr — never a silent empty value, so a failed lookup can’t quietly become an empty shell variable.

--json

Same answer, wrapped so a script can tell which field it asked for and which env replied. One JSON document on stdout, nothing else.

rbx env get universe-id --env prod --json

{
  "schema_version": 1,
  "field": "universe-id",
  "value": "9876543211",
  "results": [{ "env": "prod", "value": "9876543211" }]
}

rbx env get universe-id --env all --json

{
  "schema_version": 1,
  "field": "universe-id",
  "results": [
    { "env": "dev", "value": "9876543210" },
    { "env": "prod", "value": "9876543211" }
  ]
}

Values are always strings, including the ids: it is the same text the bare form prints, one filter reads owner-type and universe-id alike, and a 64-bit place id is never handed to a consumer that would round it.

Which of value and results you get is decided by the invocation, never by the data. --env all omits value even against a file with exactly one env, so a filter cannot start working by accident and break when a second env lands.

UNIVERSE=$(rbx env get universe-id --env prod --json | jq -r .value)
rbx env get place-id --env all --json | jq -r '.results[] | "\(.env)=\(.value)"'

Export the env map as a module your game code can import, so runtime code branches on the env it’s running in instead of hardcoding ids.

rbx env gen-module --out src/types/EnvironmentInfo.luau
rbx env gen-module --out src/environments.lua
rbx env gen-module --out config/environments.json
rbx env gen-module --out src/types/EnvironmentInfo.ts

Declaring the path once

Rather than repeating --out in your shell, your hook and your CI job, put it in rbxplace.toml:

[codegen]
output = "src/shared/Envs.luau"   # relative to rbxplace.toml

[dev]
universe_id = 9876543210

rbx env gen-module           # writes src/shared/Envs.luau
rbx env gen-module --check   # verifies the same file

This is the form to prefer wherever the check runs. A --check spelled with a different path than the generator passes green while verifying a file nobody consumes — the one failure mode a drift guard cannot afford. An explicit --out still wins when passed.

[codegen] is a reserved section, like [owner]: it is not read as an env, and every tool that rewrites rbxplace.toml preserves it.

Checking the committed copy

--check re-renders in memory and asserts the file on disk still matches rbxplace.toml, so a module that was edited by hand — or left stale after an env changed — fails instead of shipping. It stays offline, so it runs in a pre-commit hook and in CD. See Guarding generated files for the hook and CI snippets, and for the one thing that breaks the comparison.

The output is an array of environment objects, each with env, universeId, and placeIds (an array of { name, id }). Luau and TypeScript additionally get a union type of every env name:

export type EnvironmentType = "dev" | "prod"

export type EnvironmentInfo = {
  env: EnvironmentType,
  universeId: number,
  placeIds: { { name: string, id: number } },
}

local envs: { EnvironmentInfo } = { ... }
return envs

The optional env key in rbxplace.toml overrides the name game code matches on (it defaults to the section name):

[dev]
universe_id = 1234567890
env = "Dev"        # what EnvironmentType will contain
[dev.places]
main = 111111111

It renames an env; it does not alias two envs onto one. Two sections resolving to the same name — whether through two env fields or an env that collides with another section’s name — is rejected when the file loads, with both sections named. Env names are what game code matches on, so a duplicate would make every lookup by name ambiguous.

Envs and places are emitted in name order, so regenerating from an unchanged rbxplace.toml produces a byte-identical file — safe to commit and to run in a pre-commit hook.

Remove an env from rbxplace.toml and from every file keyed by it.

rbx env rm staging --dry-run   # list what would go
rbx env rm staging             # asks before writing
rbx env rm staging --yes       # for scripts

The env is named as a positional argument, not read from the global --env. This is the one command where naming the wrong env deletes something, and --env is a flag people leave set in a shell for a whole session.

What it touches, when the file exists:

rbxapikey.toml is the odd one. Every other file gives an env a table of its own, removed whole; this one names envs inside arrays — [settings] default_envs, and each key’s envs, itself either one list or one list per named group. All of them are walked. Leaving a name behind would not be untidiness: an env that rbxplace.toml no longer defines is an error to the api key commands, not something they skip, so the next rbx apikey run would fail on a file you never edited.

Emptying one of those lists is reported rather than done quietly, because it changes what a key targets. A key whose own envs is empty falls back to [settings] default_envs, so a key that named only the removed env may now reach envs it never named — a removal widening something. An emptied group is the same problem from the other side: group names are key identity, so what is left is a key declaration targeting nothing. The command prints each list it emptied and leaves the decision to you.

Everything is planned before anything is written, so a file that fails to parse stops the run rather than leaving the project half-edited. Comments and key order survive: the files are edited as documents, not reserialised through the config model.

The aggregate generated files — init.luau, the type module, whatever rbx env gen-module writes — are regenerated, not deleted, so the command names them at the end instead of touching them.

Nothing is deleted on Roblox, and nothing could be. A game pass or a developer product cannot be deleted there at all, only taken off sale; a badge can only be disabled; a universe can be deactivated and is still there. A command called destroy would be describing something it does not do, on resources people paid money for. This removes the env, which is the part that really can be removed.

An env that is not in rbxplace.toml is refused, and the error names the ones that are — a typo must not report success having done nothing. [owner] and [codegen] are top-level tables and not envs, so they are refused too.