Resolution Order
Highest precedence first:- CLI flags for config values such as
--backendor--api-base-url - Local
./.rmux.toml - Environment variables
RMUX_API_KEY- Stored hosted auth selected with
rmux auth useorrmux login
.rmux.toml is not a hosted auth source.
In CI, you can skip ./.rmux.toml entirely if the job sets the required config
env vars such as RMUX_BACKEND and RMUX_API_BASE_URL.
Use these commands to inspect and switch hosted auth explicitly:
Config Files
Legacy
rmux.conf and .rmux.conf are still read, but rmux configure writes ./.rmux.toml.
backend=managed, interactive rmux configure prompts for the hosted auth mode on every run so you can explicitly choose OAuth or API key auth for that project.
Do not commit .rmux.toml if it contains service tokens or cloud credentials.
On hosted backends, organizationId and projectId in .rmux.toml set the default scope for commands like rmux env new, rmux usage, and rmux token create.
Backend Selection
[aws], [gcp], [e2b], and [managed] tables. A single file can carry settings for multiple backends; the backend key decides which is active.
Legacy aliases local (aws) and cloud (managed) are still accepted.
Example .rmux.toml
Full Settings Reference
Core
Hosted auth is environment/session only:
AWS
GCP
E2B
Managed
The managed backend provisions sandbox environments through the control plane. Users only needbackend = "managed" plus either a stored hosted auth selection or RMUX_API_KEY for hosted auth. No cloud credentials or infrastructure settings are required.
Tooling Overrides
List-valued variables (subnet IDs, security group IDs) use comma-separated values.