18 modules, all included, all free

Core stays lean. You compose the rest.

Every capability that names a vendor, a business domain or a dependency ships as an opt-in NuGet package on the same IBarakoModule contract you can implement yourself. Reference the ones you want; AddBarakoCMS finds them in the dependency context.

ExternalAuth

Auth4.2.1

External / social sign-in module for barakoCMS: "Continue with Facebook / Google / LinkedIn / GitHub" via OAuth, matched to a global user by verified email, issuing the same tenant-scoped, device-bound token as the built-in flows. Captures profile details (photo, birthday, location) per provider.

dotnet add package BarakoCMS.ExternalAuth

Email · Resend

Email4.0.0

Resend email-provider module for barakoCMS: implements IEmailService via the Resend HTTP API, plus a delivery webhook that records bounces/complaints as EmailEvent documents.

dotnet add package BarakoCMS.Email.Resend

Accounting

Domain4.0.0

Optional double-entry accounting module for barakoCMS: accounts, balanced journal entries, and reporting.

dotnet add package BarakoCMS.Accounting

Analytics · Umami

Analytics4.0.0

Umami web-analytics module for barakoCMS: proxies a self-hosted Umami instance behind admin-only endpoints so the CMS admin can show visitors, top pages, referrers and countries, and register new tracked sites, without exposing an Umami API key to the browser.

dotnet add package BarakoCMS.Analytics.Umami

Diagnostics

Ops4.1.1

Client error logging for barakoCMS: apps POST captured browser errors (message, stack, page, user, club) to /api/client-errors; they're deduplicated by fingerprint with an occurrence count and browsable by Admin/SuperAdmin at GET /api/client-errors so you can retrieve and fix them later.

dotnet add package BarakoCMS.Diagnostics

Import

Content4.1.1

Optional bulk-import module for barakoCMS: analyze .xlsx/CSV uploads and bulk-create content. Zero-dependency parsing via Talaan.

dotnet add package BarakoCMS.Import

Files

Storage4.2.1

Optional file-attachment module for barakoCMS: upload and retrieve files (receipts, photos, documents) stored in Postgres via Marten.

dotnet add package BarakoCMS.Files

DeviceTrust

Auth4.0.0

Optional trusted-device module for barakoCMS: records the device behind each sign-in, binds sessions to devices, and can require OTP approval for new devices.

dotnet add package BarakoCMS.DeviceTrust

Portability

Ops4.2.1

Content portability for barakoCMS: export content-type definitions and their content data as a JSON bundle, and import a bundle into another instance (upsert types by name, recreate content via events). For backup, migration, seeding, and sharing content-type templates.

dotnet add package BarakoCMS.Portability

Pwa

Analytics4.0.0

PWA install tracking for barakoCMS: records when the app is added to the home screen / run as an installed app, anonymously or tied to the signed-in user, so the admin can see adoption and who installed it.

dotnet add package BarakoCMS.Pwa

FeatureFlags

Ops4.0.0

Lean feature-flag module for barakoCMS: create a flag, toggle it on/off, and target it ("true for this and that") by club, by user, or by percentage rollout. Global flags with per-tenant targeting, evaluated server-side and exposed at GET /api/feature-flags for the UI.

dotnet add package BarakoCMS.FeatureFlags

AI

Content4.1.1

AI module for barakoCMS: semantic (vector) search over published content using a self-hosted embedding model (Ollama by default). Indexes only public fields, searches only published, document-Public entries, and needs no third-party API key.

dotnet add package BarakoCMS.AI

Files · S3

Storage4.1.1

S3-compatible object storage provider for the barakoCMS Files module. Works with AWS S3, Cloudflare R2, and self-hosted S3-compatible stores such as SeaweedFS. Public files get a direct, CDN-friendly URL; private files are proxied through the API.

dotnet add package BarakoCMS.Files.S3

Templates

4.2.1

dotnet new templates for barakoCMS. barakocms-module produces a module with one capability-gated endpoint, one document type, configuration read from its own section, packaging metadata that inherits from a shared props file, and a test project on BarakoCMS.Testing.

dotnet add package BarakoCMS.Templates

Email · Smtp

Email4.0.0

SMTP email-provider module for barakoCMS: implements IEmailService over any SMTP relay (a host's mail server, Google Workspace, Amazon SES, a corporate relay) using MailKit. Registers itself only when a host is configured.

dotnet add package BarakoCMS.Email.Smtp

Testing

4.0.0

A test host for barakoCMS modules: a real barakoCMS over a Testcontainers PostgreSQL with the module under test registered, an HTTP client signed in as the seeded admin, and a tenant helper. Use it as an xunit class fixture.

dotnet add package BarakoCMS.Testing

Pages

4.2.0

Page tree for barakoCMS: refuses a parent cycle, a page too deep or a reserved root slug on a configured content type, and serves the nested navigation, path resolution with breadcrumbs, and an authenticated tree with drafts for the console.

dotnet add package BarakoCMS.Pages

Forms

4.2.0

Public forms for barakoCMS: a content type marked as a form accepts anonymous submissions at POST /api/public/forms/{slug}, validated against its own schema and stored as a Sensitive entry that delivery never serves, with a per-client rate limit, a honeypot and optional Cloudflare Turnstile.

dotnet add package BarakoCMS.Forms

The question every contribution runs into

Module, or core?

It is a module if any of these is true

Two sensible projects would disagree about wanting it

Core is what nobody gets a choice about

It names a vendor, a product or a business domain

Core’s vocabulary is content, users, tenants and permissions

It brings a dependency core does not already carry

Core’s dependency list is a promise to everyone who installs it

Removing it still leaves a working CMS

If content, auth, tenancy and delivery survive, it was never core

It is core if any of these is true

Something else cannot work without it

Content, content types, auth, tenancy, permissions

Core would need to know it exists

The moment core needs an if for your feature, it is not a module

It changes the shape of content, auth, tenancy or delivery

Those are contracts other people’s modules depend on

When it is genuinely borderline, build it as a module. Moving one into core later is additive; pulling a feature out of core breaks everyone who installed it.

Where core stands against its own rules

The rules were applied to core itself. One feature failed them and is already gone: Features/Club/ was product vocabulary rather than CMS vocabulary, and the Membership model it operated on stayed, because a feature failing the rules does not mean the model under it is wrong. The two below look like they fail the rules and are correctly core.

Features/Workflows/

Looks like a module, is correctly core: it runs as a Marten projection, and IModuleSchema exposes only For<T>(). A limit of the contract, written down rather than implied.

Features/Audit/

Looks optional, is correctly core: one read endpoint, but fifteen core files write audit entries. A module here would leave core writing records nothing could read.

Build your own the same way

A module is one contract and the hooks it needs

Contribute DI services, your own Marten documents, FastEndpoints endpoints and seed data. Core knows none of them by name. Discovery finds the assembly, so installing yours is a package reference and a restart.

Turning a module off leaves its data alone

GET /api/modules lists every module with enabled.

A name that matches nothing refuses to start

And lists the names it does know, rather than booting without it.

LedgerModule.csC#

public sealed class LedgerModule : IBarakoModule
{
  public string Name => "Ledger";
  public void ConfigureServices(IServiceCollection s)
    => s.AddScoped<IPostingRules, PostingRules>();
  public void ConfigureSchema(IModuleSchema schema)
    => schema.For<JournalEntry>();
}