Precedence
Roomote resolves configuration in layers:- Process environment variables supplied by Docker Compose, the one-command installer, a PaaS, or the shell.
- Saved deployment environment variables encrypted in Roomote during setup or from Settings pages.
- Persisted runtime settings such as the selected default model, sandbox provider, or preview settings.
- Derived defaults for local development and release-managed values.
- Provider credentials usually resolve as process env first, then saved deployment env vars.
- Model role env vars such as
R_MODELoverride the same role selected in Settings > Models. - Preview env vars such as
PREVIEW_PROXY_BASE_URLoverride values saved from the preview pane’s admin setup on the task page. - Sandbox provider credentials resolve as process env first, then saved
deployment env vars. The default sandbox provider is special: an explicit
admin selection saved in Roomote wins over
DEFAULT_COMPUTE_PROVIDERbecause local and Compose stacks often set a default automatically. - Local development has safe defaults for Postgres, Redis, MinIO, signing keys, and local URLs. Production does not.
UI locking
When a supported setting is provided by the process environment, Roomote treats it as operator-managed infrastructure. Settings pages may show the value as configured, masked, or env-managed, but they should not overwrite it. This is intentional. It lets production operators keep secrets and platform configuration in the deployment system while still letting admins manage non-env settings in the app. Use the UI when:- the value is safe for an admin to rotate from Roomote
- the setting is expected to change without redeploying
- the deployment platform does not make env management easy
- the value is required for boot, networking, or storage
- the value is a production secret managed by your host or secret manager
- you want changes reviewed in infrastructure config
- you need to prevent in-app overrides
/setup also respects env-managed provider configuration. If an inference
provider is fully configured from environment variables, setup skips the
inference-provider step. If a hosted sandbox provider such as Modal, E2B, or
Daytona is fully configured from environment variables, setup skips the sandbox
provider step too. Local Docker is still treated as the default local fallback,
so Docker-only configuration does not skip that step.
Production recommendations
For production and shared self-hosted deployments:- Set
NODE_ENV=productionandR_APP_ENV=production. - Set stable public URLs with
R_APP_URL,TRPC_URL, and, when previews are enabled,PREVIEW_PROXY_BASE_URL. - Provide
DATABASE_URL,REDIS_URL, and S3-compatible artifact storage. - Generate strong
ENCRYPTION_KEY,ARTIFACT_SIGNING_KEY, andDASHBOARD_PASSWORDvalues. - Either provide both job and preview auth keypairs or set
R_AUTO_GENERATE_KEYS=trueso Roomote generates and persists them. - Keep provider credentials in environment variables or a secret manager when they are controlled by the operator.
- Avoid
SKIP_ENV_VALIDATIONoutside build tooling or one-off diagnostics.
Naming convention
Deployment env var names follow three rules:R_*— configuration Roomote itself defines and operators set: URLs and model roles (R_APP_URL,R_MODEL), Roomote’s registered integration-app credentials (R_GITHUB_*,R_SLACK_*,R_MICROSOFT_*,R_TEAMS_BOT_*,R_TELEGRAM_*,R_DISCORD_*,R_LINEAR_*), and boot knobs such asR_AUTO_GENERATE_KEYS.- Conventional infrastructure names stay unchanged:
DATABASE_URL,REDIS_URL,S3_*,NODE_ENV,HOST,PORT. - Third-party provider credentials keep the provider’s standard names:
MODAL_*,E2B_*,DAYTONA_*,OPENAI_API_KEY,ANTHROPIC_API_KEY.
ROOMOTE_* names remain for Roomote-internal plumbing and
installer/upgrade machinery (for example ROOMOTE_APP_DOMAIN,
ROOMOTE_VERSION, and ROOMOTE_WORKER_IMAGE_REPO in installer-managed
deployments); they are intentional exceptions, documented in the
deploy/README.md naming section of the Roomote repository.
Supported env vars
The table below lists operator-supported deployment configuration. It does not include task-scoped internal variables that Roomote injects into sandboxes, such as per-task auth tokens or workspace paths.Runtime and URLs
Database, Redis, and artifacts
Security and signing
Models and inference providers
Sandbox providers
Source control providers
Communications and sign-in
During Microsoft Teams setup, Roomote uses the Microsoft Entra app values for
the Teams bot by default. Use Show advanced config after the Directory
(Tenant) ID field only when your Azure Bot app ID is different from the Entra
app ID, or when you need to set the optional bot name or token overrides.
Integrations
Declarative environments
See Environments for the
apply semantics.