Skip to main content
RemoteMux merges configuration from several sources so you can override defaults per project.

Resolution Order

Highest precedence first:
  1. CLI flags for config values such as --backend or --api-base-url
  2. Local ./.rmux.toml
  3. Environment variables
Hosted RemoteMux auth is resolved separately from project config:
  1. RMUX_API_KEY
  2. Stored hosted auth selected with rmux auth use or rmux login
Stored hosted auth is single-mode: either an OAuth session or an API key, never both at once. .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.
When 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

The config format is TOML with top-level [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 need backend = "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.
Last modified on April 9, 2026