Download the PHP package inlayphp/inlay without Composer

Inlay

PHP-first, schema-driven UI for Laravel and Inertia — one server contract, rendered by React or Vue.

Inlay is a PHP-first, schema-driven UI framework for Laravel and Inertia. It brings a fluent developer experience for forms, tables, actions, infolists, resources, and admin panels to applications that use React or Vue.

Laravel defines the interface and owns authorization, validation, querying, and persistence. Inlay serializes that intent into stable, versioned contracts. Small React and Vue packages render those contracts and handle accessible browser interaction.

The main goals are:

• Make ordinary CRUD interfaces fast to write from Laravel PHP.
• Keep business rules, policies, validation, and queries on the server.
• Give React and Vue the same public component contract.
• Allow applications and community packages to add renderers, fields, columns, actions, themes, and plugins without forking Inlay.
• Keep each feature independently installable.

Status

Inlay is under active pre-release development. The monorepo currently includes:

• Fluent PHP builders and versioned JSON contracts.
• Complete initial Form, Table, Schema, Action, Infolist, Import, and Panel component catalogs.
• PHP-first Resources with automatic Laravel routes and Inertia page delivery.
• Authenticated admin panels with automatic Resource routes and navigation.
• Native Laravel Gate/Policy authorization, optional Spatie role synchronization, and a Dcat-inspired permission manager.
• A secure media catalog core with private-by-default uploads, logical folders, trash/restore, and transformation hooks.
• Authorized and centrally validated create, update, and delete lifecycles.
• React 19 and Vue 3 renderers with matching behavior tests.
• Custom renderer registries, plugin manifests, asset registries, and render hooks.
• Semantic theme tokens, stable data-slot hooks, and typed class overrides.
• A shared neutral base theme, polished default admin theme, accessible high-contrast mode, dark mode, and PHP-defined custom themes.
• A public inlayphp/design / @inlayphp/design façade with make:inlay-theme CSS generation for application-owned themes.
• PHP-first stats, chart, and table dashboard widgets with matching React and Vue renderers.
• Opt-in, request-keyed dashboard widget caching through the Laravel cache repository, without weakening authorization or tenant scoping.
• Session- or database-backed, transport-safe notifications with optional action integration and matching React/Vue renderers.
• A Laravel 12, Inertia v3, React 19 playground using the local packages.

The API may still change before the first stable release. See Roadmap for the largest remaining compatibility areas.

Official React and Vue renderers share accessible controls through @inlayphp/ui-react and @inlayphp/ui-vue. This keeps inputs, focus treatment, custom selects, dialogs, menus, and plugin screens visually consistent without moving PHP component definitions into JavaScript.

Requirements

• PHP 8.3 or newer
• Laravel 12
• Inertia Laravel 3 for Resource page delivery
• React 19 or Vue 3 for the supplied frontend renderers
• Node.js and pnpm for monorepo development

Individual packages may require fewer dependencies. For example, the schema and support packages do not require an Inertia application.

Package map

Clean core Composer packages

These packages are installed by inlayphp/inlay. They provide the panel and component framework without activating a database permission system, media library, or import workflow in the generated panel.

Optional official Composer packages

The CMS family is intentionally excluded from this initial public monorepo bootstrap. It will be released separately after its own package and contract review, without changing the core panel, form, table, resource, or plugin APIs.

Frontend packages

Framework-neutral runtime packages:

• @inlayphp/core
• @inlayphp/actions
• @inlayphp/theme
• @inlayphp/design
• @inlayphp/ui
• @inlayphp/notifications

React packages:

• @inlayphp/ui-react
• @inlayphp/actions-react
• @inlayphp/forms-react
• @inlayphp/tables-react
• @inlayphp/infolists-react
• @inlayphp/notifications-react
• @inlayphp/imports-react
• @inlayphp/panels-react
• @inlayphp/permission-manager-react
• @inlayphp/media-manager-react
• @inlayphp/widgets-react
• @inlayphp/two-factor-authentication-react

Vue packages:

• @inlayphp/ui-vue
• @inlayphp/actions-vue
• @inlayphp/forms-vue
• @inlayphp/tables-vue
• @inlayphp/infolists-vue
• @inlayphp/notifications-vue
• @inlayphp/imports-vue
• @inlayphp/panels-vue
• @inlayphp/media-manager-vue
• @inlayphp/widgets-vue
• @inlayphp/two-factor-authentication-vue

The monorepo keeps PHP builders and their React/Vue adapters near each other so releases can keep both sides of a contract compatible.

Installation

Install the complete administration framework with two commands:

This works on a plain laravel new application too: the installer creates the missing Inertia entrypoint (resources/js/app.tsx for React or resources/js/app.ts for Vue), root Blade view, HandleInertiaRequests middleware, and renderer/Vite dependencies before it creates the panel. It also creates and registers AdminPanelProvider, enables the default theme, authentication and account settings, generates a working User Resource, redirects guests to the panel login, scaffolds the official renderer pages, and configures Tailwind to scan the installed @inlayphp/* npm packages. Media is available as an explicit opt-in with --media, which registers the Media Manager, publishes its migrations, and adds its renderer page. The original Laravel app.js entrypoint is kept in the Vite inputs when present, so a stock welcome route continues to work. It detects npm, pnpm, Yarn, or Bun and installs the required renderer packages. Run the printed migration, user, and frontend build commands, then open /admin.

The installer writes this Tailwind CSS 4 source rule automatically. Keep it in the application stylesheet when deploying from a standalone repository:

inlay:doctor checks panel registration, the official renderer dependency, Tailwind source discovery, generated User and Media files, and compiled CSS. Run it without --production before building, or with --production after the Vite build to prove the deployed stylesheet contains Inlay utilities.

inlay:make-user uses hidden password and confirmation prompts. Its --name, --email, and --password options are available for controlled automation, but putting passwords directly in shell history is not recommended.

Use --panel=reports for another panel id, --media to install the optional Media Manager, --without-media as a backwards-compatible no-op alias, or --without-users for a smaller preset. Use --no-npm when CI manages frontend installation separately, and --force to replace generated application files. React and Vue are both turnkey renderer presets. Select Vue explicitly when the application uses the Vue starter kit (or when starting from a plain Laravel application):

The installer preserves existing starter-kit dependencies and application-owned Vue entrypoints while adding the Inlay page wrappers and Vite/Tailwind wiring.

The installer is repeatable. Running it again preserves application-owned providers, Resources, pages, and validation files while restoring missing supporting files. Use --force only when you intentionally want to replace the generated application code.

For a tenant-aware starter panel, provide the Eloquent tenant model while installing. The generated provider imports the model and calls tenant() for you; tenant membership is still decided by your model's TenantAccess and HasTenants implementations:

This generates routes such as /{team}/workspace and keeps the tenant configuration in application-owned PHP, where it can be reviewed and extended. Omit --tenant-route-key to use the model's normal Laravel route key.

The root package is the recommended all-in-one installation foundation and includes the storage-neutral media catalog dependencies. Media Manager is activated only with php artisan inlay:install --panels --media; roles, database permissions, Spatie adapters, imports, two-factor authentication, and CMS features remain separate plugins so a default panel stays understandable.

Install only the features an application uses. A Form and Table application typically needs:

For React:

For Vue:

Add model-centric CRUD orchestration with:

Vue resource pages use @inlayphp/resources-vue. Both adapters render owner-scoped Relation Managers from the same PHP-defined Forms and Tables.

Compose Resources into a protected panel with:

Add Dcat-style access management and the media library as independent panel plugins:

Their required backend foundations are installed transitively: Permission Manager installs the Spatie authorization adapter, and Media Manager installs the storage-neutral media catalog. Register them through the same panel plugin API used by community extensions:

Use @inlayphp/media-manager-vue and @inlayphp/permission-manager-vue for a Vue panel. Both official plugin renderers expose the same page registries and contracts as their React counterparts. Install inlayphp/imports with its React or Vue renderer only when an application needs import workflows.

All public Composer packages are available from Packagist and the official React/Vue renderers are available from npm. The monorepo uses local workspaces only for development and release verification.

See Installation and deployment for clean Laravel, standalone Forms/Tables, custom renderer, CI, and Laravel Cloud workflows.

Quick start: a PHP-first Resource

Generate the resource, its list/create/edit pages, and a centralized validation class:

Standalone pages outside a panel have their own generators:

Each scaffolds the page class, derives its Inertia component name and query-string prefix from the class name, and prints the Route::inlayForm() or Route::inlayTable() line to register it. Existing files are never overwritten without --force.

The central resource can configure its table and form once:

Each page selects an Inertia component while remaining connected to the Resource:

Register the full CRUD route set without writing a controller:

For this Resource, Inlay registers:

The application frontend only renders the supplied contracts.

Reusable resource shells can also consume the PHP page contract directly: ResourcePage renders server-authored breadcrumbs, actions, header/footer widget dashboards, Forms, Tables, Infolists, and RelationManagers in either React or Vue. Widget themes and custom renderers remain replaceable through the same WidgetDashboard options used by panel dashboards.

React:

Vue:

See the full Resources documentation for routing options, lifecycle hooks, scoped queries, security guarantees, and advanced persistence.

Forms

Forms support nested layouts, initial data, defaults, validation metadata, conditional visibility, conditional requirements, live change/blur metadata, and Inertia submission.

Available initial field types include text, textarea, select, checkbox, checkbox list, radio, toggle, toggle buttons, hidden, color, date/time, upload, slider, tags, key/value, code, Markdown, rich text, repeater, and builder fields.

Tables

Tables can execute allow-listed Eloquent searching, sorting, filtering, and pagination from request input. Only columns and filters explicitly marked as supporting a query operation can change the query.

Named, server-authored views reuse the same allow-listed query contract in React and Vue:

The selected view is transported as {table}_view; explicit search, filter, sort, grouping, and page-size parameters override its defaults. Standalone TablePages also expose Save, Edit, and Delete controls when a personal-view store is enabled. The default store is session-scoped; applications that need cross-device persistence can bind TableViewStore to the database driver and publish the optional inlay_table_views migration.

The initial catalog includes text, badge, boolean, icon, image, color, select, toggle, text-input, and checkbox columns; select, boolean, ternary, text, date, and numeric filters; row/header/bulk actions; selection; loading and empty states; and responsive pagination.

Centralized validation

Validation rules belong in one reusable Laravel class instead of being copied between a field schema, Form Request, import, and Resource controller.

Generate application-owned validation classes with php artisan make:inlay-validation User, then execute the same validation from forms, imports, actions, or APIs through Inlay\Validation\ValidationRunner.

ValidationContext provides:

• Operation, such as create, edit, or an application-specific operation.
• Source, such as Form, Import, API, Action, or bulk processing.
• Prepared input data.
• Current record and authenticated user.
• Consumer-specific options.

Profiles also support custom messages, attribute labels, after-validation callbacks, dependency injection, and stop-on-first-failure behavior.

Resource persistence lifecycle

Resource mutations follow this order:

Applications can customize small lifecycle steps without replacing the controller:

Resources are fail-closed until canAccess() is implemented. Record lookup always uses the Resource query, so tenant or visibility scopes cannot be bypassed by passing a model identifier directly.

Infolists, imports, and panels

Infolists render read-only record details with the same shared layouts:

Imports provide column mapping, previews, centralized row validation, authorization, casting, isolated failures, persistence callbacks, and matching five-step React/Vue wizards. Queue transport and storage remain application-owned.

Panels define branding, paths, navigation groups, middleware, theme, plugins, and the application shell from PHP. The Admin package adds login/logout, a protected dashboard, automatic Resource CRUD routes, and Resource navigation. React and Vue renderers provide responsive side/top navigation, active states, badges, user menus, breadcrumbs, SPA-link adapters, and slots.

Theming and layout customization

Inlay supports three customization levels:

1. Theme tokens for product-wide color, radius, and control sizing.
2. Root classes and typed per-slot class maps for page-specific layout changes.
3. Renderer registries for replacing built-in components or adding community components.

Choose the quiet shadcn-style foundation or the polished Inlay admin preset entirely from PHP:

Theme::base() supplies a neutral zinc foundation. Both presets use semantic tokens—background, surface, foreground, muted, border, hover, status colors and status surfaces, overlays, radius, sizing, font, and shadow—so an application theme automatically reaches panels, forms, tables, actions, infolists, imports, media, permission pages, and widgets. New applications should import Design from inlayphp/design; the lower-level Theme and @inlayphp/theme APIs remain compatible for existing apps. Panel also forwards application-defined semantic tokens as scoped CSS variables, so community packages can add a token without forking the core theme.

Generate a PHP theme class and matching CSS variables instead of hand-writing the integration:

This creates app/Inlay/Themes/BrandTheme.php and resources/css/inlay/brand.css. The stylesheet includes light variables plus OS-preference and [data-theme="dark"] overrides. See inlayphp/design for the complete generator and frontend API.

Stable semantic attributes make CSS overrides independent of internal Tailwind utility classes:

Plugin and renderer contracts reject duplicate ownership so two extensions cannot silently replace the same component. Plugin registration is atomic: shared registries roll back if registration fails.

Public wire contracts

Every top-level PHP object serializes a named, versioned contract:

Current top-level contracts include:

• inlay.forms.v1
• inlay.tables.v1
• inlay.actions.v1
• inlay.infolists.v1
• inlay.imports.v1
• inlay.panels.v1
• inlay.resources.v1
• inlay.media-manager.v1
• inlay.themes.v1
• inlay.widget-dashboard.v1

Adding optional keys is backward-compatible. Changing the meaning or shape of an existing key requires a new contract version.

Arbitrary PHP closures never cross the Inertia boundary. Dynamic behavior must be resolved on the server or represented as explicit, allow-listed condition/action metadata.

Security model

The packages enforce several boundaries by default:

• Resource authorization is fail-closed.
• Resource records are resolved through the Resource’s scoped Eloquent query.
• Authorization occurs before mutation validation and persistence.
• Only validated input reaches Resource persistence.
• Eloquent fillable/guarded rules remain active.
• Resource writes and lifecycle hooks are transactional.
• Tables only apply declared searchable, sortable, and filterable query operations.
• URLs are normalized by a shared safe-URL policy that rejects executable and protocol-relative values.
• Conditions and component types use explicit allow lists.
• Page paths reject traversal, malformed encoding, and record-placeholder mismatches.
• Fresh builders are required to prevent mutable state leaking between long-running requests.
• Extension registries reject ownership collisions and roll back failed plugin registration.
• Panel routes declare abilities and enforce Laravel Gate decisions before returning or mutating data.
• Media uploads are private by default, use randomized object keys, and enforce configured size, MIME, and extension allow-lists.
• Media delivery uses short-lived signed URLs, authorization, private cache headers, and nosniff; untrusted formats download instead of rendering inline.
• Media deletion is recoverable until an explicit permanent-delete operation, and folder moves prevent cycles and logical orphans.

Application policies, domain-specific validation, database constraints, CSRF protection, authentication middleware, malware scanning, storage lifecycle rules, and rate limiting remain application responsibilities.

Community extensions

Community packages should be able to provide:

• Custom Form fields and renderers.
• Table columns, filters, and actions.
• Infolist entries.
• Action modal content.
• Panel plugins and navigation.
• Theme presets and semantic CSS.
• Shared PHP and frontend packages that register the same renderer key.

Custom components should publish a stable PHP payload, declare a renderer category, register a unique renderer key, and provide matching React and/or Vue implementations. The Core package supplies version compatibility checks and ownership-safe registries.

The community schema-view template is a cloneable, continuously tested example containing a Composer component plus React and Vue adapters. It demonstrates stable renderer naming, nested schema rendering, deferred data, registry ownership, package exports, and compatibility checks.

Repository layout

Run the playground

Open http://127.0.0.1:8013/admin and sign in with [email protected] / password.

The playground demonstrates:

• A Resource-defined Form and Table.
• Authenticated login/logout, a dashboard, and a responsive admin shell.
• PHP-generated Resource navigation and protected CRUD routes.
• Server-side search, filters, sorting, and pagination.
• Conditional fields and Precognition metadata.
• Central validation shared with imports and Resource mutations.
• Transactional create, update, and delete routes.
• Accessible action confirmation.
• Theme tokens, class overrides, and collapsible code examples.
• Roles, permissions, user-role assignment, and an audit comparing registered, missing, synced, and stale abilities.
• A working media browser with seeded assets, folders, search, MIME filtering, uploads, metadata editing, trash/restore, and a reusable picker.

Monorepo development

Install dependencies from the repository root:

Run PHP syntax and Pest tests:

Run the complete release-oriented gate sequentially so declaration generation cannot race the export audit:

The individual frontend commands remain available when iterating on one layer:

Verify the Laravel playground:

The main test suites use Pest for PHP, Vitest with Testing Library for React/Vue, PHPStan/Larastan for Laravel static analysis, TypeScript and vue-tsc for adapter contracts, and production builds to verify package declarations and exports.

GitHub Actions runs the same package gates plus a separate PHP 8.4 / Node 22 integration job for playground/laravel-react. That job installs the playground's committed Composer and pnpm lockfiles, runs its full Pest suite, type checks, lint/format checks, and production build, so demo routes, migrations, and renderer wiring cannot silently drift away from the packages they demonstrate.

Documentation

Start with the Inlay user guide. It is organized as a progressive Laravel walkthrough: clean installation, panels, Resources, Forms, Tables, schemas/infolists, centralized validation, actions/widgets, themes, plugins, standalone pages, and deployment. Each chapter links to the package README for the full method-level API.

The same Markdown sources power the static documentation site in docs-site/. Run its local dev server while editing the guides, or let the included GitHub Pages workflow publish the generated site from main.

For contribution workflow, feature proposals, testing expectations, and the package/renderer boundaries, read Contributing. Report security vulnerabilities privately through Security; do not use public issues for sensitive reports.

• Release checklist and split-package process
• Architecture and package boundaries
• User guide index
• Getting started
• Panels
• Resources and CRUD
• Forms
• Tables
• Schemas and Infolists
• Validation
• Actions, notifications, and widgets
• Themes and UI customization
• Plugins
• Standalone Forms and Tables
• Testing and deployment
• Component matrix
• Focused Laravel, React, and Vue examples
• Resources and CRUD lifecycle
• Forms
• Tables
• Actions
• Notifications
• Validation
• Imports
• Infolists
• Panels
• Core extensions and plugins
• Authorization
• Spatie authorization adapter
• Permission manager
• Media catalog
• Media manager
• Spatie media adapter
• Two-factor authentication

Roadmap

The next major milestones are:

1. Deepen resource page and widget composition. Parent-scoped nested resource URLs, hosted action-form sub-transports, selection-aware bulk action modals, per-record bulk outcome reports, an allow-listed per-page chooser, removable filter indicators, PHP-declared filter form layout, per-column search and sort callbacks, safe header and per-record cell attributes, column actions, scoped and custom summarizers, arbitrary schema filters, closure-backed column and table presentation, fluent Relation Groups, and keyboard-accessible React/Vue tabs are available. Resource and Relation Manager soft deletes include scoped query, filter, row/bulk action, lifecycle, React/Vue, test DSL, and playground support. Validated pivot-aware create/attach/edit forms, secure searchable attach/detach, and HasMany/MorphMany associate/dissociate UI are available.
2. Dashboard widget caching is available through the opt-in CacheableWidgets provider contract. Resource header actions now use the resource action boundary with page authorization and render through the shared React/Vue Actions runtime, including confirmation, action forms, lifecycle responses, and custom transport hooks. Remaining page-level action UX and resource composition hardening are next, and panel widget providers can be discovered from an explicit application namespace. The standalone notification contract, session/database delivery, action integration, and React/Vue renderers are available.
3. An optional two-factor authentication plugin with encrypted TOTP/recovery state, challenge and authenticated settings routes, and React/Vue challenge and security-settings renderers. Existing Fortify models can reuse their encrypted columns through Inlay's dependency-free storage adapter, and QR rendering remains an application-edge contract. An opt-in Fortify challenge bridge can keep Fortify as the authentication owner while using the shared Inertia Form page. Panels exposes the ordered post-credential LoginStep pipeline required by the native plugin.
4. Async relationship option loading and direct-to-storage upload adapters need broader application fixtures and release hardening across both renderers.
5. Responsive layouts, relationship-group automation, and advanced bulk selection. Server-authored named views, owner-scoped personal save/edit/delete persistence, query-wide filtered CSV exports, selection-aware bulk CSV downloads, queued export payloads, and the optional first-party PhpSpreadsheet XLSX driver now reuse the same authorized React/Vue contract. Grouping, summaries, and column management have their first production-tested React/Vue slice.
6. Rich text/code editor integrations are available; deeper schema reactivity and long-tail editor extension documentation remain release work.
7. Vue playground parity is available for standalone Form/Table routes, the panel dashboard, a real UserResource CRUD comparison (list, create, and edit), the package-owned media-manager page, permission-manager access pages, and two-factor settings. Package-owned Vue plugin pages resolve through the same panel shell as local pages. Multi-panel discovery is available through PanelRegistry::directoryFor() and the React/Vue PanelSwitcher; remaining work is the long-tail Vue plugin-page sweep, tenant-aware starter kits, and reusable application starter kits.
8. The media manager now exposes a bounded filesystem storage browser with a stable PHP/React/Vue contract; community S3/API browsers can register through MediaStorageRegistry. Media albums/collections, manager filtering, image focal-point metadata editing, bounded usage/reference inspection, and opt-in queued transformations are available.
9. Coordinated package versions, changelogs, upgrade guides, the first signed release tag, and community extension documentation. The split and npm publishing automation plus common registry metadata are now in place; the first public release still needs organization credentials and an explicitly approved version line.

The project does not aim to move Laravel business logic into React or Vue. Frontend adapters should stay replaceable; PHP contracts remain the durable public API.

License

Inlay is intended to be released under the MIT License. See individual package metadata for the current license declaration.