Environment Variables

Environment variables are the strongest configuration source for a Roomote deployment. They are best for values that belong to infrastructure: public URLs, database and Redis connections, storage credentials, provider API keys, signing keys, and production-only overrides. Most day-to-day setup can also be managed from the Roomote UI. Use environment variables when you want configuration to be explicit, reproducible, managed by your deployment platform, or unavailable to in-app editors.

​

Precedence

Roomote resolves configuration in layers:

1. Process environment variables supplied by Docker Compose, the one-command installer, a PaaS, or the shell.
2. Saved deployment environment variables encrypted in Roomote during setup or from Settings pages.
3. Persisted runtime settings such as the selected default model, sandbox provider, or preview settings.
4. Derived defaults for local development and release-managed values.

The exact order depends on the setting. A few important cases:

• Provider credentials usually resolve as process env first, then saved deployment env vars.
• Model role env vars such as R_MODEL override the same role selected in Settings > Models.
• Preview env vars such as PREVIEW_PROXY_BASE_URL override values saved from Settings > Live Previews.
• 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_PROVIDER because 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

Use environment variables when:

• 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

​

Production recommendations

For production and shared self-hosted deployments:

• Set NODE_ENV=production and R_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, and DASHBOARD_PASSWORD values.
• Either provide both job and preview auth keypairs or set R_AUTO_GENERATE_KEYS=true so Roomote generates and persists them.
• Keep provider credentials in environment variables or a secret manager when they are controlled by the operator.
• Prefer immutable worker image tags for hosted sandbox providers.
• Avoid SKIP_ENV_VALIDATION outside 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_LINEAR_*), and boot knobs such as R_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.

A few 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

​

Integrations

​

Declarative environments

See Environments for the apply semantics.

​

Live previews

​

Observability and request timing

​

Local development and deploy helpers

​

Environment variables versus environment settings

Roomote also has environment variables inside Settings > Environments. Those are task workspace variables: they are made available to Roomote tasks running in that environment. This page is about deployment configuration variables. Deployment variables configure Roomote itself; environment variables inside an environment configure the codebase Roomote is working on.