Configure providers and plugins
Configure the app factory
import { createQentrahApp, type QentrahConfig } from "@qentrah/cms";
const config: QentrahConfig = {
name: "My CMS",
plugins: { register: [] },
};
export default createQentrahApp(config);Configuration map
| Field | Purpose |
|---|---|
providers | Runtime-specific persistence, storage and related adapters |
collections | Collection directory and synchronization settings |
plugins.register | Explicit plugin list |
plugins.disableAll | Disable both core and user plugins and plugin bootstrapping |
email | Custom provider or built-in resend, sendgrid, or console |
routes | Path and Hono handler pairs |
middleware.beforeAuth / afterAuth | Middleware around authentication |
auth.extendBetterAuth | Extend authentication configuration |
version / name | Application identity |
Provider selection
Choose adapters for the actual target runtime. The package includes database support for SQLite, D1, PostgreSQL and Neon, and storage support for local files, S3-compatible storage and R2. Required bindings, credentials and migrations are supplied by the consuming deployment.
Email fallback
An explicitly supplied email provider takes precedence. A named built-in can use its environment settings; otherwise the implementation checks provider environment variables and falls back to the console provider. Console delivery logs messages rather than sending email. Configure a real provider before relying on password-reset or magic-link delivery.
Explicit plugin registration
plugins.directory and plugins.autoLoad are deprecated no-ops. Put plugin instances in plugins.register; plugin routes are mounted before the admin catch-all.
Source captured: 2026-10-11