System Settings

ObjectStack includes a settings service for runtime and plugin settings. ObjectOS exposes those settings through the Console when the application artifact requires the settings capability.

Settings model

Settings are declared by code and stored as values:

Plugins should not create one-off settings tables for ordinary configuration. They should declare settings manifests and let ObjectOS render and store values consistently.

Resolution order

Each setting declares a scope (global, tenant, or user). The resolver walks the cascade from highest to lowest precedence and the first value that is set wins:

Environment override (locked)
Global setting
Tenant setting
User setting
Manifest default

Environment overrides are locked. If a value is set through an environment variable, the Console UI shows it as managed by the host and rejects runtime edits. A locked value anywhere up the chain also locks the effective value, so lower scopes cannot shadow it.

Common settings areas

Customer-facing settings usually include:

Secrets

Password and credential fields should be encrypted by the settings service or provided as environment-managed values. When a secret provider is configured, the settings service stores the ciphertext in sys_secret and keeps only a handle in sys_setting. Do not store secrets in artifacts, compose files, or Git.

Test actions

Settings manifests can declare standard action buttons, such as:

• send test email;
• test SSO discovery;
• verify object storage credentials;
• validate webhook target.

Use these actions for customer setup flows instead of asking operators to inspect logs first.

Related

Several settings areas have dedicated configuration guides:

• Email
• Storage
• AI providers
• Authentication and SSO
• Runtime