Repository navigation
feat(config): add deployment settings for self-hosted and cloud - #78
Merged
Merged
Conversation
Add the deployment settings document (execution limits, model, container runner) with one strict parser shared by the file and the dashboard: an unknown key, an out-of-range value, a credential-shaped string or bad YAML refuses the whole document. Read the edition and the settings source from CODE_ZERO_EDITION and CODE_ZERO_SETTINGS_SOURCE, never from the host, and refuse the dashboard source on the cloud edition. The instance file is now config.yml by default; an explicit CODE_ZERO_CONFIG still wins, and code-zero.deployment.yml is read when it is the only file present. The timeout is named for what it limits: one repository command (command_timeout_minutes), not a whole run.
Add deployment_setting (a singleton row holding the settings document the dashboard source edits) and organization_setting (an organization's own stricter limits on the managed cloud, removed with the organization), with migration 0006 and the queries the composition root reads and writes them through, including the member-role lookup used to authorize changes.
Add settings.get, settings.update, settings.export and settings.organization.get/update. Self-hosted, only an admin session reads them, and writes are refused on the server unless the dashboard is the source. On the managed cloud a customer sees service status (configured or not, nothing else) and the plan's limits; an organization owner or admin may lower the organization's limits, never above the plan, with membership checked in the store on every call. API keys and operator tokens can neither read nor change settings. Refusals are audited. tasks.create, runTask and the scheduler apply the resulting RunPolicy: invalid settings refuse every run, allowed modes are checked before a task is recorded, concurrency is capped deployment-wide and per organization, and the settings are applied over .code-zero.yml with the stricter value winning.
Build the settings authority in server/utils/settings.ts from the environment, the instance file and the store: exactly one source, the file's settings sections reported as ignored rather than merged when the dashboard is the source, and service status reported as configured or not, never how. Pass it into the RPC and OpenAPI contexts, and hold webhook deliveries and polling passes to the same policy: invalid settings start nothing, and a repository whose mode the settings disallow is skipped.
Add /settings and a settings module on the typed oRPC client. - Self-hosted, file source: the settings read-only, the file to edit, every issue by path when they are invalid, service status, and YAML export. - Self-hosted, dashboard source: an editable form for execution limits, model and container runner, with bounds as hints only; the server's per-field issues are shown beside each field, plus pending, saved and error states, who saved last and when, and download or copy as config.yml. - Managed cloud: service status, plan limits read-only, and the active organization's limits, editable for owners and admins and read-only for members, with the effective limits. The page re-reads when the sidebar switches organization. - A refusal (for example a non-admin on self-hosted) renders as a message. The timeout is labelled per command. Controls the server does not enforce are not shown. Adds the Settings nav entry and the g s shortcut, EN and IT copy, and unit and component tests.
Add a Deployment settings guide: editions, the two self-hosted sources, the config.yml format with a validated example, editing and export from the dashboard, what is locked on the managed cloud, the per-command timeout, and the controls that do not exist yet. Add the settings authority boundary to docs/architecture.md (included by the guide), CODE_ZERO_EDITION and CODE_ZERO_SETTINGS_SOURCE to the environment reference and apps/web/.env.example, and move references from code-zero.deployment.yml to config.yml.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Architecture 
Inside the changed components — 1 viewComponent view — Control Plane Policy & Scheduling Internal details of how settings authority governs router, task operations, and scheduler queues. 
Data flow 
The other flows — 1 sequence
Review ✨ Nothing flagged · reviewed Tip Run 🪧 More tips
Thanks for using PR Lens! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out on X, Bluesky, Mastodon, Reddit or LinkedIn |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Under a network ceiling below `full`, a repository that chose container isolation could still name its own container network. `restricted` is the one policy where the container runner reads that name, so `network: host` became `--network host` while the run reported restricted networking. The repository's network name is now dropped whenever the deployment narrows the network, not only when the deployment imposes its own sandbox. The settings parser ignored top-level keys outside its three sections, because the deployment file shares its top level with control_plane and poll. A mistyped `exection:` was therefore accepted and left every limit at its permissive default. Any top-level key that belongs to neither half is now refused; documents saved from the dashboard accept only the settings sections.
…ation Saving organization A, switching to B and letting B's read finish first installed A's answer when it arrived: the form showed A's limits under B's name, and the next save went to A. The limits form is now keyed by organization, an answer for an organization the page no longer shows is dropped, and a settings read superseded by a newer one is discarded however late it lands.
This branch was previously deployed
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.
Summary
Related to #5. Deployment settings for both editions, on top of #72: where they come from, who may change them, and how every run is held to them.
CODE_ZERO_SETTINGS_SOURCE.file: the instance fileconfig.yml(or an explicitCODE_ZERO_CONFIG). The new Settings page shows it read-only, with each problem listed by path when it is invalid.dashboard: an administrator edits the settings on the page, they are stored in Postgres, and they export as aconfig.ymlwith no secrets..code-zero.ymlstays the per-repository file, and the stricter of the two wins.CODE_ZERO_EDITION=cloud, never inferred from the host): the AI provider, sandbox, database and mail come from the service and cannot be changed. Customers see only whether each one is configured, never how. The plan sets the ceiling, and organization owners and admins may lower concurrency, the command timeout and the allowed modes for their own organization.0006adds the deployment and organization settings tables.Why
A self-hosted deployment should be able to keep its configuration in a file it versions, or manage it from the dashboard; the managed cloud needs settings customers cannot loosen. Keeping exactly one source active at a time means the page can never show a value the server is not using.
Verification
aube run check:repoaube run lint:ciaube run typecheckaube testaube run buildSafety and compatibility
observemode as read-only, or explained the policy change above.Settings mutations need a signed-in session; API keys and operator tokens are refused. The export and the service statuses never carry a credential, URL or host. Observe is always allowed. Deployments must run migration
0006.code-zero.deployment.ymlis still read when it is the only file, with a note to rename it.Agent context
Reviewer notes
/api/v1/settings/**exists in the OpenAPI surface, but that transport takes bearer credentials only and the settings procedures refuse those, so nobody can use it today. Hide it, or allow it for admin API keys later?CODE_ZERO_EDITIONvalue is treated as cloud with every run refused, failing closed.i18n:reportlists the new settings keys as unused because it only scansapps/web/app/**, notapps/web/modules/**.
No outstanding findings block merging. All three previously reported issues are addressed in the current code.Reviews (2) · Last reviewed commit: "fix(web): keep a late settings answer fr..." · Reviewed by Greptile