Skip to content

Aurora 1.0: install it into any Laravel site, with passkeys and two-factor sign-in.

What's new →

Architecture

How Aurora is built

A Laravel package with a Filament admin, a block system your app extends, and one set of tools shared by editors, the assistant and MCP.

The big picture

The package and your app

vendor/aurora/cms

Aurora (the package)

Models, the admin panel, the media library, forms, menus, translations, the AI assistant and the MCP server. Installed with Composer, updated like any package.

app/

Your app (the website)

Your page template, your blocks and their views, your settings tabs and your styles. Registered with Aurora from your own service provider.

The rule is simple: Aurora never depends on your app. Where it needs something from the website (its blocks, its settings, the view a page is drawn with) it offers a hook, and your app calls it. That keeps upgrades boring.

The stack

Laravel 13

Models, queues, mail, authentication and the HTTP layer.

Filament 5

The admin panel: resources, forms, tables and actions.

Livewire & Alpine

The canvas and every interactive screen.

Tailwind CSS

The admin theme and, if you like, your website.

Content model

Pages are blocks, stored as JSON

A page has a title and address per language, a status, SEO fields and a list of blocks. Containers (sections, grids, button groups) hold other blocks in named slots.

  • Text that differs per language sits beside the blocks, per block
  • Every save writes a revision with a full snapshot
  • Files are referenced by media library id, so replacing a file updates every page
pages.blocks[0] JSON
{
  "id": "b7f2…",
  "type": "hero",
  "data": {
    "layout": "centered",
    "headline": "Pages are layouts, not *forms*",
    "primary_label": "Get started",
    "primary_page": "01a1…"
  }
}
One block as it is stored: its type and its data.

Editors, the assistant and MCP

One set of tools, three ways in

The canvas, the in-panel assistant and MCP clients all change content through the same operations, checked against the same permissions, and each change is recorded as a revision.

  1. 01

    Someone asks

    An editor drags a block, or asks the assistant, or Claude calls add_block over MCP.

  2. 02

    Aurora checks

    The person's role decides whether the change is allowed, whoever is doing the typing.

  3. 03

    Content changes

    The page is saved as a new revision, with the person and the channel (canvas, assistant or MCP).

  4. 04

    Everyone sees it

    Open editors reload, reviewers are notified, and the activity log shows what happened.

Hooks

Extending Aurora

What your app registers, and where.

app/Providers/AppServiceProvider.php PHP
use Aurora\Blocks\Blocks;
use Aurora\Support\SettingsTabs;

public function boot(): void
{
    // The blocks editors can use, in palette order.
    Blocks::register([HeroBlock::class, CardBlock::class, CodeSampleBlock::class]);

    // Settings your templates read, kept per site.
    SettingsTabs::register('footer', fn (): Tab => Tab::make(__('Footer'))->schema([
        TextInput::make('footer_note'),
    ]), siteKeys: ['footer_note']);
}