Managed objects
How the seed owns the objects it lists, and how it keeps secrets out
Single-row sections are all or nothing
ldap, settings and chat are a single row each, so the seed must declare all their fields; the other sections are lists.
A seed that omits a field refuses to start and names it:
Config seed failed, refusing to start: Seed file validation failed: /settings must have required property 'mail_server'
Declare an empty value explicitly with "" or false. A few fields are optional, and one that is omitted is left unchanged:
| Section | Optional fields |
|---|---|
ldap | description, credential (a credential to bind with) and groupfilter |
chat | auth_type, api_version, request_user, ignore_certs and extra_headers |
settings | None |
settings covers only the mail fields and the URL; all other settings stay editable.
The file holds no secrets
Each ${VARIABLE} is replaced with that environment variable (on Kubernetes, from a Secret), so the file can live in Git.
A variable that is not set is a fatal error, so a placeholder can never end up stored as a password.
Credentials can also use a secret store (secret_store, secret_ref); vault_path goes away in 8.
Managed objects
An object that comes from the seed is flagged managed:
- It is enforced on every start, so the file stays authoritative.
- It is read-only: the API answers 403, the interface disables Edit and Delete, and its own page says it comes from the config seed file and is read only.
- Only the seed can set or clear the flag.
Objects created by hand are never touched, unless the seed declares the same name. That record is then adopted: the declared fields are enforced and it becomes read-only. Adoption is logged as a warning and in the audit trail.
Applying the seed is idempotent: records that already match are left alone, so a restart normally reports 0 updated.
A declared repository whose working tree is missing is cloned again on every start, so a failed first clone is retried. The Repositories row of the Status page shows any repository without a working tree.
Removing an object
Removing an object from the file releases it: the record stays and becomes editable again. Deleting a whole section does the same.
Add prune: true to a list section to delete the managed records the file no longer declares:
credentials:
prune: true
items:
- name: production-db
# anything else the seed used to manage is deleted
prune never deletes a record created by hand.
Turning the seed off
Unsetting CONFIG_SEED_PATH does not release anything: the seed is no longer applied, and the records it managed stay managed and read only. To edit them again, release them first: point CONFIG_SEED_PATH at a file without them (an empty file declares nothing and releases every record), let it apply at a start or a reload, then unset the variable. The released records stay as they are, and become editable.