Settings
Settings in the admin dashboard is grouped into four areas. Anyone signed in can read it; changes need the Admin role or above.
These sections store structured, typed data for your public website. Each is one record, readable without authentication at GET /api/v1/public/settings/{module} and through cms.settings.* in @kenresoft-cms/astro. A module that was never saved returns an empty object.
| Section | Module | Holds |
|---|---|---|
| General | general |
Public site name, tagline, logo (a media file) |
| Contact | contact |
Email, phone, address |
| Social | social |
A list of links (platform, label, URL) |
| Navigation | navigation |
Menu items, each targeting a URL or a Page, with order, visibility and new-tab options |
| Footer | footer |
Description, copyright text, footer links |
| SEO | seo |
Default title and description, default social share image, Google site verification |
General also has a separate Deployment identity name. That is the name shown in the admin itself, and it can differ from the public site name.
Experience
Section titled “Experience”- Appearance: Light, Dark or System theme for the admin.
System
Section titled “System”- Cache: shows the public API cache lifetimes (entries 5 minutes, media files 1 year) and a manual purge that clears the cached entries and media in batches. The cache is also cleared automatically when content changes.
- Advanced: named feature flags for this deployment. A flag has no effect unless code checks for it.
Notifications, Security, Storage and Database sections appear as “coming soon” and have no controls yet. Per-account two-factor authentication is on your Profile page.
Developer
Section titled “Developer”- API: CORS origins, the Live Preview URL templates, links to the OpenAPI document and Scalar reference, and a Developer experience toggle that shows a Developer panel on Content Types, Entries, Forms and Media with endpoints and code snippets. Admins and Owners always see it once enabled; Editors and Authors need a per-user grant on the Users page.
- Webhooks: send signed HTTP POST requests to your endpoint when entries are created, updated, published, unpublished or deleted. A webhook can cover one content type or all. Each has a signing secret, shown once when created or regenerated, and a delivery log. Failed deliveries retry up to 5 times on the 5-minute cron. Webhooks are Admin and above only.
Related: Environment variables for deployment-level configuration that is not editable here.