Introduction

Inlay is a Laravel-native visual composition layer for existing applications. A developer registers ordinary Blade components as blocks; Inlay gives the people who work with content a packaged admin to compose pages from them, edit their settings, preview against the real frontend, and publish - without the developer building any admin UI of their own.

Supported Laravel versions: 11, 12, and 13. Requires PHP 8.2+, and Livewire ^4.0 for the admin.

Inlay is pre-1.0. The API described in these docs is the current, intended shape, but this isn't yet a stable release.

Core concepts

Four things compose together, each covered in its own chapter:

| Concept | What it is | | --- | --- | | Block | A reusable Blade component you register once (Hero, ImageWithText) - see Registering blocks. | | Page Section | One placed instance of a Block on a specific Page, with its own settings overrides - created when an editor adds a Block from the picker. | | Page | An ordered list of Page Sections, plus its own title, public path, and metadata - see The editor. | | Page Definition | An optional developer-authored policy restricting which Blocks a kind of Page may contain - see Page Definitions. |

What Inlay is

• A package you install into an existing Laravel application, not a standalone CMS or a new application you build on top of.
• A way to expose a safe, schema-driven subset of your own Blade components as blocks for visual composition, with the schema derived from your block's own constructor - not a separate config file that can drift out of sync with your code.
• Frontend-agnostic. Inlay renders your blocks through Laravel's real Blade/Livewire pipeline and never ships its own frontend framework, CSS reset, or JavaScript bundler dependency into your application's output. Your blocks look and behave exactly as you built them, in whatever design system your application already uses.

What Inlay is not

• Not a page builder that generates markup. You write real Blade components as blocks; Inlay composes and persists references to them plus their settings. It never invents HTML.
• Not a theming system. There is no Inlay design language leaking into your public pages - only the admin has its own (self-hosted, Tailwind-free) design.
• Not a drag-and-drop layout engine. A page is a flat, ordered list of blocks rendered inside whatever layout your own route or controller already provides. There are no nested blocks, slots, or regions in this release.
• Not a rich-text platform, a media library, or a navigation builder. These are explicitly out of scope for the current release - see Current limitations.
• Not Livewire Volt, even where the ergonomics rhyme - see Single-file blocks for the authoring style Inlay uses instead.

Quick example

Register a block against a handle:

// config/inlay.php
'blocks' => [
    'hero' => \App\Inlay\Blocks\Hero::class,
],

// app/Inlay/Blocks/Hero.php
namespace App\Inlay\Blocks;

use Illuminate\View\Component;
use Illuminate\View\View;
use WeArePixel\Inlay\Attributes\Text;
use WeArePixel\Inlay\Contracts\InlayBlock;

final class Hero extends Component implements InlayBlock
{
    public function __construct(
        #[Text(label: 'Heading', maxLength: 80)]
        public string $heading = 'Welcome',
    ) {}

    public function render(): View
    {
        return view('blocks.hero');
    }
}

Someone managing content can now add a Hero to a page from the admin, edit its heading, preview it against your real frontend, and publish - all without you writing a single line of admin UI.

See Installation to get a working admin up, or Registering blocks for the full authoring reference.