# PagibleAI and the Laravel CMS that keeps content in a nested tree

> PagibleAI is an API-first CMS package for Laravel that installs into an existing application, with structured content, a versioned draft and publish cycle, a JSON:API for delivery and a GraphQL admin API, plus AI generation and an MCP server for LLM-driven editing. The interesting part is the package split, and the interesting constraint is that it is a package you add to your app rather than a platform you run.

**aimeos/pagible** — Easy, flexible and powerful cloud-native Laravel CMS package powered by AI with JSON:API, GraphQL API, templates, and themes

- Repository: https://github.com/aimeos/pagible
- Website: https://pagible.com
- Stars: 599 · Forks: 16
- Language: PHP
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/aimeos-pagible

## A CMS package, not a CMS platform

PagibleAI CMS is described in the README as an API-first content management system that can be installed into any existing Laravel application, combining the ease of use of WordPress with the structured content management capabilities of Contentful, powered by AI for content generation, image manipulation and translation.

That framing determines everything about how you adopt it. There is no separate service to run, no separate admin domain to secure, and no migration of your existing content model into someone else's platform. The CMS lives inside your Laravel application, uses your database, and is installed with a Composer command and an Artisan command.

The scale claim in the README is deliberately wide, saying it scales from a simple blog to a multi-tenant, multi-domain CMS serving millions of pages, and from a single SQLite-backed page to database clusters. The features list backs the multi-tenancy half of that with multi-domain routing, multi-tenancy capability, multi-language support, and a backup package with per-tenant backup and restore.

The topics list is worth a glance too, because it names the neighbourhoods this project positions against: contentful, wordpress, headless-cms, jsonapi and graphql. The headline comparison in the README title, simple as Wordpress and the power of Contentful, is the project's own framing.

The audience is a Laravel team that wants an editor interface and a content model, and owns everything around it.

## Twelve packages, each usable on its own

PagibleAI is a modular monorepo split into focused sub-packages, and the README states that each package handles a specific concern and can be used independently.

Core provides the data models, which are Page, Element, File and Version, along with multi-tenancy, permissions and migrations. Admin delivers the Vue.js admin panel with drag and drop page management. GraphQL exposes the admin API through Lighthouse for content editing, and JSON:API provides a read-only frontend API for content delivery. That split is the key design decision: the write path and the read path are different APIs with different trust assumptions.

AI integrates LLM providers through Prism and Prisma PHP for content generation, image manipulation and translation. Search implements a custom Laravel Scout engine supporting FTS5 on SQLite, MATCH and AGAINST on MySQL, tsvector on PostgreSQL and CONTAINSTABLE on SQL Server. MCP offers more than 30 tools for LLM-driven content management. Backup provides per-tenant backup and restore with media files, integrity verification and cross-tenant support. Import provides importers from external CMS platforms such as WordPress. Cashier sells frontend page access through subscriptions or one-time payments using Stripe, Paddle or Mollie, with separate adapter packages for each. Theme handles frontend rendering with Blade templates, and Themes holds the frontend themes.

The project structure listing shows the same arrangement on disk, with src/ as a meta-package that acts as an install orchestrator and provides a serve command, and a shared tests/ directory with an aggregated phpunit.xml runner at the root.

## The nested set tree and the immutable version model

Two mechanisms explain how the content model actually behaves.

The first is the tree. Pages are organised as a nested set tree using _lft and _rgt columns, which is the classic nested set model, and the page tree is drag and drop in the admin panel. The alternative, a path or adjacency list model, would need a recursive query for every subtree operation, and the nested set gives you subtree reads in one indexed range scan. The cost of nested set is that moving a page rewrites the _lft and _rgt values of everything between the old and new positions, which is fine for a CMS and a nuisance for a high-churn structure.

The second is versioning. All content changes are tracked as immutable version snapshots, and the split is between what editors see and what the public sees: editors see the latest draft while the public sees the published version. The feature list adds the operations that implies: save, publish, schedule and revert drafts, and a full version history and audit trail.

Caching is per page with a configurable duration, which sits at the right level for a CMS where a page is the unit a visitor navigates to.

The remaining model pieces are Element, which is the extensible content element type that lets you define new content elements in seconds, and File for media. Shared content is assignable to multiple pages, so a fragment can be edited once and appear in several places.

## Installing into a Laravel application

The prerequisites are PHP 8.2 or higher, Composer, Node.js and npm for admin panel development, and a working Laravel 11.x, 12.x or 13.x installation.

If you do not have a Laravel application yet, you create one first:

```bash
composer create-project laravel/laravel pagible
cd pagible
```

Then the CMS itself is two commands:

```bash
composer req aimeos/pagible
php artisan cms:install
```

The cms:install command does three things: it publishes the files, it migrates the database, and it adds the commands updating the published CMS files after each composer update to the post-update-cmd script in your composer.json. That last part is the detail that saves a maintenance headache later, because a package whose published assets drift from the package version is a package that breaks on upgrade without saying so.

Two configuration details follow. The README says to change the APP_URL setting in the .env file of your application to your domain, and if you are using php artisan cms:serve for testing, to add the port of the internal web server, such as APP_URL=http://localhost:8000, otherwise uploaded files will not load. cms:install warns you if the port is missing.

The other detail is the robots.txt. Fresh Laravel applications contain a static public/robots.txt file which web servers serve before Laravel receives the request, and cms:install removes it if it contains the default rules of Laravel, so Pagible's dynamic route can serve the published rules together with the generated sitemap URLs. If the file contains custom rules, you copy them into the robots.txt configuration element of the root page, publish the change and remove the file afterwards.

## Users, permissions and selling access to a page

Authorisation is handled with an Artisan command, and the README is careful about what it does:

```bash
php artisan cms:user -e editor@example.com
```

This adds admin privileges for the specified user, and the point worth noting is that it works for users who do not exist yet, so it also creates them. The README points to the authorisation and permissions page for the rest of the model, and the Core package is where permissions live.

The second capability is the Cashier package, which sells access to restricted frontend pages through subscriptions or one-time payments, using Stripe, Paddle or Mollie. The adapter split into cashier-stripe, cashier-paddle and cashier-mollie packages means the payment provider is a replaceable part rather than a hardcoded one.

That feature is what makes the CMS a multi-tenant commercial platform rather than just a blog engine, and it is also the feature that brings the most operational responsibility. Payments, subscriptions, entitlements and refunds are not things a CMS should be doing for you unless you are prepared to own them.

The remaining integration surfaces in the feature list are an importers for WordPress and other external CMS platforms, a multi-language layer, and the MCP API with more than 30 tools for LLM-driven content management, which lets an agent create and edit content through the same model the GraphQL admin API exposes.

## What to weigh before installing

Three considerations come out of the documentation itself.

The first is that this is a package inside your application, so the maintenance relationship is different from a hosted CMS. The update cycle is your composer.json, and the cms:install command exists specifically to keep the published files in step with each composer update. Every version bump of the CMS package is a change to your application's vendor tree, and any drift between the published assets and the package is something you own.

The second is the frontend story. The JSON:API package is read-only, and the Theme package renders with Blade templates while the Themes packages hold the actual front end assets. So the delivery path is either your own front end consuming the JSON:API, or the bundled Blade theme. There is no separate storefront to run, but there is also no hosted front end to fall back on.

The third is the framework range. Laravel 11.x, 12.x and 13.x are all supported, and PHP 8.2 or higher. The repository has a .circleci directory for CI, phpstan.neon.dist for static analysis, a benchmark/ directory, a pulse/ directory, cdn/ and webhooks/ directories, and a testbench.yaml for package testing, which is the shape of a project with real engineering behind it.

The licence is MIT, and the README's acknowledgements section points to the projects it builds on, including the Aimeos commerce platform. A 0.13.x version line with releases on 2026-09-30, 2026-10-02 and 2026-10-12 is moving quickly, so a new installation should expect its first upgrade sooner rather than later.

## Conclusion

PagibleAI is a good fit for a Laravel team that wants WordPress-style editing with Contentful-style structured content inside an application it already owns, because the CMS is a set of installable packages and the frontend delivery API is read-only, which keeps the public surface narrow. It is a poor fit for a team that wants a turnkey CMS, since the project assumes a working Laravel installation and a publishing workflow you configure yourself. Before adopting, plan the install against a real Laravel version, since 11.x, 12.x and 13.x are all supported, and read the notes on the APP_URL setting and the robots.txt handling, because both are the kind of detail that silently breaks a public site on first deploy.

## FAQ

### How do I install PagibleAI CMS into a Laravel application?

Create the Laravel application first with composer create-project laravel/laravel if needed, then run composer req aimeos/pagible and php artisan cms:install. The install command publishes the files, migrates the database and registers a post-update-cmd hook that refreshes the published CMS files after each composer update.

### What databases does PagibleAI CMS support?

The search engine is a custom Laravel Scout implementation supporting FTS5 on SQLite, MATCH and AGAINST on MySQL, tsvector on PostgreSQL and CONTAINSTABLE on SQL Server, and the README describes scaling from a single SQLite-backed page to database clusters.

### Does PagibleAI CMS support multiple languages and tenants?

Yes. The feature list includes multi-language support, multi-domain routing and multi-tenancy capability, with the Core package providing the tenancy implementation and the Backup package offering per-tenant backup and restore with media files and cross-tenant support.

### How do I give someone access to edit content in PagibleAI CMS?

Run php artisan cms:user -e editor@example.com. The command adds admin privileges for that address and can create the user if they do not exist yet. The admin backend itself is served under the application domain, and the authorisation and permissions page covers the finer-grained model.

## Sources

- [aimeos/pagible on GitHub](https://github.com/aimeos/pagible)
- [License: MIT](https://github.com/aimeos/pagible/blob/master/LICENSE)
- [Project website](https://pagible.com)
- [README](https://github.com/aimeos/pagible/blob/master/README.md)
- [Releases](https://github.com/aimeos/pagible/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aimeos-pagible