Where it is

Settings → Schema (/admin/settings?tab=schema) — only visible when schemaEditEnabled is true in site config. For production sites this is usually off; for dev and onboarding it's on.

What the tab lets you do

Add, remove, reorder, and retype fields on collections without editing cms.config.ts by hand. Changes take effect immediately — no restart, no build step.

The tab lists every collection with:

• Name (internal id) and label (display name)
• Field count
• Edit schema button — drills into the field editor
• + New collection — scaffolds a new collection with your chosen fields and kind

Editing a collection

Click Edit schema on any collection. The editor shows:

• Collection meta — name, label, kind (page / snippet / data / form / global), description, urlPrefix, urlPattern, previewable
• Fields — drag to reorder, click to edit, trash icon to remove
• Add field — pick a field type from the palette
• Blocks — if the collection uses the blocks field type, edit the block registry here

Save to write changes. The CMS updates the in-memory schema, regenerates webhouse-schema.json, and fires the save hook to any downstream consumers.

Field types you can add

text, textarea, richtext, number, boolean, date, image, image-gallery, video, audio, htmldoc, file, interactive, column-slots, map, select, tags, relation, array, object, blocks.

Each field has a standard set of options (required, default, description) plus type-specific options (select has options[], relation has collection, array has fields[], etc.).

The care-required operations

Some schema changes can silently break existing content. The tab warns before you commit, but know what you're doing:

• Renaming a field — existing documents still have the old key in their data object. Either rename via a migration script or leave the old field (the CMS ignores keys not in the schema — the data is still there, just not shown in the editor).
• Removing a field — the data stays on disk, the editor just hides it. Add the field back any time to see the data return.
• Changing a field type — HIGH RISK. A richtext field's markdown won't fit into a text field; a relation turned into tags loses the references. The tab blocks the most destructive type changes; others show a warning.
• Changing kind — e.g. page → data removes URL generation. Existing URLs 404 after the next deploy. Set up redirects first.
• Removing a collection — don't. Trash the documents first, then remove. Otherwise the data files stay on disk orphaned.

Re-export the schema for non-TS consumers

If your project has non-TypeScript consumers (Java, .NET, PHP, Python, Ruby, Go), the webhouse-schema.json file is the contract. Any schema change via this tab re-generates that file automatically and writes it to the project root.

Commit both cms.config.ts and webhouse-schema.json in the same commit. See Framework consumers for why this matters.

Disabling schema edit

For production sites, set SCHEMA_EDIT_ENABLED=false (or remove the env var). The tab disappears from the sidebar. Editors can't change the schema; only a developer with repo access can.

Related

• Collections — conceptual overview of collections
• Field types — full field type reference
• Collection metadata — the kind and description rules
• Framework consumers — why webhouse-schema.json must stay in sync