[Feat] Provision environments declaratively from files at startup - #26
Merged
brunobergher merged 2 commits intoJul 9, 2026
Merged
Conversation
Author
|
No code issues found. See task
|
Author
|
Fixed both outstanding review issues in f4ebc64:
Both behaviors are covered by new real-database tests ( |
brunobergher
marked this pull request as ready for review
July 9, 2026 12:34
brunobergher
requested review from
brunobergher,
daniel-lxs and
mrubens
as code owners
July 9, 2026 12:34
brunobergher
pushed a commit
that referenced
this pull request
Jul 9, 2026
* feat: provision environments declaratively from files at startup * fix: contain declarative dir failures and defer orphaning on invalid definitions --------- Co-authored-by: Roomote <roomote@roomote.dev>
mrubens
deleted the
feature/declarative-environment-provisioning-0pvws3rizy1nm
branch
July 12, 2026 04:19
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Self-hosted deployments can now provision environments declaratively at startup, infrastructure-as-code style, instead of creating them through the web UI or the setup agent:
ROOMOTE_ENVIRONMENTS_DIRpoints at a mounted directory of environment definition files (*.yaml,*.yml,*.json), one environment per file.ROOMOTE_ENVIRONMENTS_YAMLaccepts inline multi-document YAML for PaaS-style deployments (Railway/Render/Fly) where mounting files is awkward.Definitions use exactly the same
EnvironmentConfigYAML format as the environment editor's YAML view. The API applies the combined set on every boot (non-fatal, with the same advisory-lock + pending-migration retry pattern as the auth-keypair bootstrap):filesource.updateEnvironmentDefinition's existing diff.declarative_sourcemarker and returns the environment to normal manual management.ROOMOTE_ENVIRONMENTS_DIRis skipped the same way, so inlineROOMOTE_ENVIRONMENTS_YAMLdefinitions still apply. Nothing blocks API startup.orphaningDeferred), so a temporary typo in a still-present file never strips its environment's managed marker.Supporting changes:
environments.declarative_source, andenvironments.created_by_user_idis now nullable to represent system provisioning. The scheduled snapshot-refresh job now falls back to the first active user for job attribution when an environment has no creating user.ROOMOTE_ENVIRONMENTS_DIR/ROOMOTE_ENVIRONMENTS_YAMLare added to the control-plane env var denylist (reserved from the env-var editor, stripped from task sandboxes) and forwarded throughdocker-compose.self-host.yml..roomote/environments/roomote.yamlas a living example, with a schema-freshness test so it can never drift fromenvironmentConfigSchema.environments.mdx,environment-variables.mdx), and.agent-guidance/features/environment-management.mdcoverage of the new write path.Why this change was made
Teams that treat Roomote deployments as cattle want fully working environments without human intervention, environment definitions kept in git (so agents can maintain them alongside code changes), and fast dev-environment resets. Environments were previously only creatable through browser-session-gated UI flows or the setup agent.
Impact
Operators can bring up a deployment with its environments defined entirely in version-controlled files, keep them in sync via redeploys, and restore local dev environments after a DB reset with one env var (
ROOMOTE_ENVIRONMENTS_DIR=$PWD/.roomote/environments pnpm dev). Existing UI/agent environment management is unchanged; declaratively provisioned environments are clearly badged but stay editable. Verified end-to-end against a live dev database: first apply created the Roomote environment from the dogfood file, second apply reported unchanged.Screenshots