DEV Community: Aimeos

Best AI CMS 2026: 8 compared on drafts, models and MCP

Aimeos — Thu, 05 Nov 2026 16:45:11 +0000

Every CMS advertises AI now. Sometimes that's a rephrase button, sometimes an agent that builds whole pages. In half of the eight CMSs I checked, AI output isn't validated against your content model at all, or only partly. And the details developers care about are usually buried in pricing tables and docs:

Does AI output go live immediately or into a draft?
Is it validated against your content model?
Can you choose the model, or are you locked to the vendor's?
Is AI part of the product or an Enterprise add-on?
Can agents like Claude or ChatGPT work with your content via MCP?

TL;DR

Free AI with your own model: Drupal, PagibleAI and WordPress
Hosted with the strictest guardrails: Sanity
Built-in AI only on paid plans: Contentful, Payload and Strapi
AI output checked against the content model: PagibleAI and Sanity, in Contentful if you turn it on
MCP servers that save agent changes as drafts: Contentful, PagibleAI, Sanity and Strapi (with Draft & Publish)

AI feature comparison

✅ yes · ⚠️ partly or with conditions · ❌ no · ❓ not documented or closed source

	Contentful	Drupal	PagibleAI	Payload	Sanity	Storyblok	Strapi	WordPress
Create/change pages by chat	⚠️	✅	✅	❓	✅	⚠️	❌	❌
Generate text for any field	✅	✅	✅	✅	✅	⚠️	⚠️	⚠️
Translate whole pages	✅	✅	✅	⚠️	✅	✅	✅	⚠️
Generate images	⚠️	⚠️	✅	⚠️	✅	❌	❌	✅
Edit images	⚠️	⚠️	✅	❓	⚠️	❌	❌	✅
Alt text	✅	✅	✅	❓	✅	✅	✅	✅
AI changes as drafts	✅	⚠️	✅	❓	✅	⚠️	⚠️	⚠️
AI output validated	⚠️	❌	✅	❓	✅	⚠️	⚠️	❌
Own model per task	✅	✅	✅	⚠️	❌	⚠️	⚠️	✅
No credits or Enterprise plan	❌	✅	✅	❌	⚠️	⚠️	❌	✅
Runs on your own server	❌	✅	✅	✅	❌	❌	✅	✅
MCP server	✅	⚠️	✅	✅	✅	✅	✅	⚠️

PagibleAI also transcribes audio and can uncrop and upscale images. Of the others, only Drupal offers transcription, as a speech-to-text API for developers.

Statamic and Craft CMS aren't in the table because neither has first-party AI features; both rely on third-party addons. Craft 5.12 (November 2026) ships an MCP server in core, while Statamic only has community servers.

Contentful

AI Actions cover translation, rewriting, alt text, SEO and custom prompts. A Content Operations Agent is in beta. You can bring your own model via OpenAI, AWS Bedrock, Google Vertex AI, Azure or any OpenAI-compatible endpoint. AI Actions can't generate images; for that, Contentful offers a separate AI Image Generator app that uses DALL-E with your own OpenAI key.

Entries stay drafts until someone publishes them, and automations can check AI output against the target field's rules if you turn that on.

You'll only get AI Actions as an Enterprise/Premium add-on with metered credits. The $300/month Lite plan doesn't include them, and Contentful is SaaS only.

The remote MCP server has been free and generally available since July 2026, and there's also a local MIT server. New entries are drafts, but agents can also publish them directly, limited by the user's permissions and an admin allow-list of tools.

Drupal

Drupal has the broadest AI ecosystem. The AI module bundles CKEditor AI, automators, a chatbot and observability, and supports 48 AI providers. Drupal CMS 2.0 adds optional page generation from prompts with Canvas agents. Everything is GPL and free.

No other CMS here supports more providers, and Drupal's revisions and Content Moderation apply to AI changes, too. Translations can be created as drafts.

You have to combine several separate projects yourself, though. And Canvas' own docs warn that the AI can return invalid component IDs or enum values that cause render errors.

The MCP Server module is still in beta, and the Drupal AI docs advise against connecting outside agents to critical sites before a stable release.

PagibleAI

PagibleAI is an MIT-licensed CMS package for Laravel, and its AI features are part of the open source package: a chat that creates, refines and translates pages, page-wide refine prompts, text generation for any field, queued translation of whole pages, image generation and editing (inpaint, erase, remove background, uncrop, upscale), alt text and audio transcription.

Every AI change is saved as a draft version you can diff in the history. Output is checked against the JSON schema that also defines the editor form, and the same schema lets you exclude fields from translation with "translate": false.

Each task can use its own provider and model from 40+ providers, including Anthropic, OpenAI, Gemini, Mistral, Ollama and DeepL. There are no AI credits, you pay the providers directly. Switching a task to another provider takes a few lines in your .env file:

CMS_AI_WRITE=anthropic
CMS_AI_WRITE_MODEL=claude-sonnet-5
CMS_AI_WRITE_API_KEY=...
CMS_AI_TRANSLATE=deepl
CMS_AI_TRANSLATE_API_KEY=...

It requires Laravel, though. It's also the youngest CMS here, with a smaller community and no plugin marketplace yet.

The built-in MCP server has 43 tools, uses OAuth via Laravel Passport and checks the user's permissions on every call. Agent changes are saved as drafts, and only users with publish rights can put them live.

Payload

Payload is MIT-licensed and self-hosted, with drafts and versions in its open source core. Its first-party AI is part of Payload Enterprise and closed source: a writing assistant and auto-embedding for AI search, with AI translations and image generation marked as "coming soon".

Drafts and versions work well and come with the free core.

Without Enterprise, you depend on community plugins for AI. The AI code isn't public, and the docs don't say whether AI changes become drafts or are validated against your fields. Payload says the writing assistant works with "your preferred LLM", but doesn't document how you configure it.

The official MCP plugin runs on your own server and respects Payload's access control. The docs don't say whether agents can publish.

Sanity

AI Assist handles field instructions, translation, image generation and alt text from the Growth plan ($15 per seat). Agent Actions (Generate, Transform, Translate, Prompt, Patch) and the chat-based Content Agent are available on all plans, including Free, with 1,000 AI credits per month.

Of the hosted options, Sanity keeps AI on the shortest leash. Agent Actions know your schema, and Content Agent stages edits as drafts that a person publishes.

You can't bring your own model, Sanity picks it. Content lives in the proprietary Content Lake, and version history depends on the plan (3 days on Free, 90 on Growth).

The hosted MCP server works within the user's role and writes into drafts or releases, and publishing is a separate tool call. Custom validation rules in your schema don't run for MCP writes, though.

Storyblok

AI translations, alt text, ideation and SEO are included on all plans, even the free Starter plan with 25k credits. Storyblok Agents (beta) run chat and scheduled tasks on Growth ($99/month) and up, and every write needs manual approval.

Getting started costs nothing, and a person has to approve every agent change.

There's no image generation. Your own AI provider is limited to the top tiers, and version history covers 1 day on Starter and 30 days on Growth. Validation is partial: the Management API checks maximum lengths and block counts, but regex patterns only apply in the Visual Editor.

The hosted MCP server has 155+ tools in read-only, mutating and destructive modes, and can publish.

Strapi

Strapi AI offers a chat assistant in the Content-Type Builder, AI translations and AI metadata (alt text, captions). It needs the Growth license ($45/month for 3 users) with 1,000 credits per month.

The Content-Type Builder assistant helps you design content models, which none of the others offer.

There's no writing assistant for content and no image generation. The Community edition has neither AI nor content history, and your own model requires Enterprise. If Draft & Publish is off, AI translations go live right away and overwrite manual edits in the target locale.

Strapi 5.49 made its built-in MCP server generally available on all plans. It's off by default and runs inside your instance. With Draft & Publish enabled, new entries land as drafts, and agents can publish them within the token owner's permissions.

WordPress

The official AI plugin (formerly "AI Experiments") reached 1.0 in May 2026. It's free and has 18 opt-in features: titles, excerpts, summaries, rephrasing, meta descriptions, alt text, image generation and editing, tag suggestions, comment moderation and more.

You choose the provider per feature (Claude, Gemini, OpenAI and others via provider plugins). Most features produce suggestions that a person applies, so AI doesn't change content behind your back.

The features work on single fields and posts, not whole sites. Translation isn't part of the plugin; Jetpack AI offers it with a small free quota and paid plans. Generated texts aren't validated against blocks, and generated images go straight into the Media Library.

The official MCP Adapter plugin only exposes read-only abilities by default, so what agents can do depends on what your plugins register. WordPress.com has a hosted MCP server that can write and publish.

Which one should you use?

If you're on WordPress, check whether the free AI plugin is enough. If it isn't, look at Drupal and PagibleAI.
If you want a hosted CMS, Sanity has the strictest guardrails, but you can't choose the model. Contentful sells AI Actions as an Enterprise add-on.
If you want to pick your models freely, Drupal and PagibleAI support the most providers.
If you work with Node.js, Strapi and Payload include MCP for free, but built-in AI needs Strapi Growth or Payload Enterprise.
If you work with Laravel, PagibleAI gives you all AI features for free.

How I compared

I went through the official docs, changelogs and pricing pages of eight CMSs in November 2026. For WordPress, Strapi and PagibleAI, I also checked draft handling and validation in their source code. Drupal's Canvas docs already state that AI output isn't validated, so I skipped the source check there. Payload's AI is closed source, so its cells stay open. I didn't run paid Enterprise trials, and features only documented behind sales calls are marked as such.

Last updated: November 5, 2026

Sources

Contentful: pricing, AI Actions, bring your own model, AI Image Generator, remote MCP
Craft CMS: MCP in 5.12
Drupal: AI module, providers, speech-to-text, AI Translate, Drupal CMS 2.0, Canvas AI, MCP Server
PagibleAI: pagible.com, GitHub, Prisma providers, MCP setup, JsonSchema.php, Ai.php, Variants.php, Imagine.php
Payload: Enterprise AI, AI framework, MCP plugin
Sanity: pricing, Agent Actions, Content Agent, MCP server
Storyblok: pricing, AI assistance, Agents, MCP server, API validation
Strapi: AI, pricing, MCP server, MCP docs, ai-localizations.ts, validators.ts
WordPress: AI plugin 1.0, Jetpack AI, MCP Adapter, WordPress.com MCP, Title_Generation.php, Import_Base64_Image.php, bulk.ts

Which AI features do you actually use in your CMS, and which ones did you turn off again? I'm curious what works in real projects.

Aimeos 2026.10: MCP tools for Laravel e-commerce

Aimeos — Tue, 27 Oct 2026 13:03:34 +0000

Aimeos is an open-source e-commerce framework for Laravel applications. Version 2026.10 adds MCP tools that let AI agents search products, update orders and manage customers in your shop.

An agent could retrieve selected products, draft improved descriptions and save the changes after your approval. Aimeos provides the tools for reading and updating shop data; your integration handles the agent workflow and approval step.

What's new

MCP tools for AI agents

Model Context Protocol (MCP) gives AI applications a standard way to discover and call tools. The new ai-admin-mcp extension provides tools for more than 20 shop domains, including products, categories, orders, customers and stock. Depending on the domain, agents can search and aggregate records, save and delete items, and change category trees.

composer require aimeos/ai-admin-mcp

Each tool validates its arguments and checks permissions using the Aimeos context supplied by your integration. In admin/mcp/resource you configure which user groups may call which tool.

The package doesn't include an MCP transport or SDK. Each tool exposes an input schema and returns its results as PHP arrays.

Your integration registers the tool definitions with an MCP server and routes calls to their execution methods. Expose only the tools you need. The MCP package README shows how to retrieve the tool catalog, inspect definitions and execute calls.

WebMCP in the storefront

WebMCP is a proposed browser standard that lets websites describe actions for AI agents. The Aimeos storefront now uses it on the forms for addresses, saved baskets, coupons and product watch lists. Browser agents that support WebMCP can fill these forms for the customer. Few browsers support it yet, and for regular visitors the forms work as before.

Choose an AI provider for each task

In the admin backend, you can write and translate texts, generate images and remove image backgrounds with AI. In 2026.10, these features use Prisma (aimeos/prisma), our PHP library for AI providers. You can configure a different provider and model for each task. Switching providers later is a configuration change.

Imports and exports

Customer, product, category and supplier imports can combine file data with configured values. For example, set a fixed product.status in the import mapping and omit the repetitive status column from your CSV.

Order, product and subscription exports can be extended with project-specific data before the files are written, for example fields your ERP or CRM system expects.

Framework support

Laravel 10 to 13 remain supported, Symfony 8 and TYPO3 14 are now supported too.

Security hardening

Customer password hashes are excluded from loaded customer items and API responses. Admin APIs apply tighter checks to shared items and customer group assignments.
HTML sanitization and output encoding strengthen XSS protection. Remote image and CMS media fetching blocks internal addresses to protect against SSRF.
Checkout steps require POST requests. Guest orders can't be linked to existing accounts by e-mail, and site settings can't overwrite internal configuration keys.

For published vulnerabilities and affected versions, see the core security advisories.

How Aimeos fits into your application

You can install Aimeos (LGPLv3) into an existing Laravel application as a Composer package. It uses your routes, middleware, authentication, queues and Blade views.

Use the JSON:API for a custom frontend, or start with the server-rendered HTML components included with Aimeos. GraphQL and now MCP cover administration.

Aimeos is multi-vendor, multi-language, and multi-currency capable so you can run several shops with their own catalogs, prices, languages and currencies.

Aimeos is self-hosted, so you control your shop database and hosting, with no Aimeos fees per transaction. Data sent to external AI services depends on the provider and features you configure.

Get started

You can install different packages, depending on your needs:

# Full shop system
composer create-project aimeos/aimeos

# Headless API
composer create-project aimeos/aimeos-headless

# Laravel package only
composer require aimeos/aimeos-laravel

New to Aimeos? Follow the Laravel setup guide or explore the demo shop.
Upgrading an existing shop? Read the upgrade guidance before updating your dependencies.
Building an agent integration? Install aimeos/ai-admin-mcp and use the tool catalog example to connect the tools to your MCP server.

You can find the application source on GitHub.

If you like Aimeos, give it a star! :-)

PagibleAI CMS 0.13: Review with AI, publish with confidence

Aimeos — Mon, 19 Oct 2026 09:11:04 +0000

PagibleAI is an MIT-licensed CMS for Laravel with visual editing, versioned content, and APIs for headless frontends and AI agents. It runs on PHP 8.2+ with Laravel 11, 12 or 13.

PagibleAI 0.13 helps you review content before publishing and keep connected systems updated afterwards. Ask the AI assistant to check a page, inspect its changes in the history, and publish when you're ready. Optional webhook and CDN packages notify your integrations and purge affected URLs.

Review a page before publishing

Version 0.13 teaches the AI assistant built-in SEO rules for page reviews. Just click on the magic AI button and the assistant checks heading structure, meta description, canonical and robots settings, broken links and more. It explains what it found and you can then ask it in the chat to apply all suggestions or parts of it to the draft before you publish.

Before publishing, open the redesigned history dialog. Large text diffs collapse to the changed passages, and unpublished versions are marked clearly, so you see exactly what the AI and your colleagues changed.

To enable the chat, set its provider and API key with CMS_AI_WRITE and CMS_AI_WRITE_API_KEY, as described in the AI configuration guide.

Edit without losing your place

Visual editing now opens content fields in a sidebar next to the preview. Change a headline while its layout stays visible, then check desktop, tablet and phone sizes. The element picker adds search, group tabs and descriptions.

Press Ctrl/Cmd+K to jump to a page, element, file or action with the new command palette. Ctrl/Cmd+S saves; Ctrl/Cmd+Shift+S opens the publishing menu.

Trigger integrations with signed webhooks

Publishing often starts another task: updating a search service, rebuilding a static frontend, or sending content to another channel.

The optional aimeos/pagible-webhooks package sends tenant-scoped notifications through Laravel's queue when pages, elements or files are published, deleted, restored or purged, and when pages are moved (page.published, element.deleted, file.purged and so on).

Each notification identifies what changed:

{
  "event": "page.published",
  "tenant_id": "tenant",
  "timestamp": "2026-09-14T12:00:00.000+00:00",
  "data": {
    "id": "01995d6a-cb84-7218-9bb9-79063c4bf681",
    "version_id": "01995d6a-cb84-7218-9bb9-79063c4bf682",
    "path": "products/example",
    "domain": "example.com"
  }
}

Requests use Standard Webhooks signatures. The webhook verification guide provides a complete Laravel receiver covering signature and timestamp checks, duplicate deliveries and queued processing. For a search integration, your job fetches the current content to update the external index, or removes an entry when content is deleted.

Manage and test subscriptions in the admin panel. Temporary failures trigger retries with increasing backoff, while terminal responses such as 404 stop delivery.

Run this check during deployment to validate endpoint settings, deny-list entries, queue timing and cache configuration:

php artisan cms:webhooks:check

The command also warns about subscription secrets that can no longer be decrypted.

Purge CDN caches when content changes

When you correct a price or headline, your CDN needs to stop serving the old copy.

The optional aimeos/pagible-cdn package purges Cloudflare, Fastly and Varnish automatically.

With your provider configured and queue workers running, the package purges affected page URLs and public files removed from storage through queued jobs. Publishing a URL change queues purges for both the old and new address.

For Cloudflare, configure your token and zone, then choose how long public pages may stay cached:

CMS_CDN_CLOUDFLARE_TOKEN=...
CMS_CDN_CLOUDFLARE_ZONE=...
CMS_CDN_MAXAGE=86400
CMS_CDN_STALE=60

CMS_CDN_MAXAGE=86400 lets the CDN cache public pages for a day. CMS_CDN_STALE=60 allows a stale copy for up to a minute while refreshing it or if your server is unavailable.

Pages that only show a changed navigation entry stay cached until they expire, so pick a lifetime your site can live with.

PagibleAI also caches complete public pages in Laravel's cache, a separate layer from the CDN. The admin panel's "Clear cache" action clears a page and its subpages from the application cache and, with the CDN package configured, queues their CDN purges too. After a theme change, you can purge all CDN content:

php artisan cms:cdn:purge --all

Catch content errors before submitting updates

The new content schema endpoint in 0.13 lets your frontend, form builder or AI agent read registered content, metadata and configuration definitions, including those added by themes and extensions:

GET /cms/schema

The endpoint returns a JSON Schema Draft 2020-12 document. This excerpt shows the required title field inside a hero element's data object:

{
  "type": "object",
  "properties": {
    "title": { "type": "string", "minLength": 1 }
  },
  "required": ["title"]
}

A missing title or an empty string fails validation before your integration submits the update.

Use a Draft 2020-12 validator to check the full content, meta and config object, or select an individual element definition. Write changes through GraphQL or MCP.

Import content from TYPO3 and WordPress

A new TYPO3 importer brings pages, content and files over to Laravel, preserving the page tree.

Re-importing the same domain and post slug with the WordPress importer now updates and republishes the existing article instead of creating a duplicate. Each run publishes the imported changes and preserves publication dates and cover images.

Both importers are available through the optional aimeos/pagible-import package. They read directly from the source database, configured as a Laravel database connection:

php artisan cms:t3-import --connection=typo3 --file-base=https://example.com/fileadmin
php artisan cms:wp-import --connection=wordpress --domain=example.com

Install or upgrade

Add the CMS to your Laravel application with the PagibleAI installation guide.

Already using PagibleAI? Review the PagibleAI upgrade guide before updating your application.

The webhooks and CDN integrations are separate packages you add when you need them:

composer require aimeos/pagible-webhooks aimeos/pagible-cdn

When an editor publishes a change, which systems does your application need to update?

If you like PagibleAI CMS, give it a star :-)

The Best Laravel CMS: PagibleAI vs Statamic vs October CMS

Aimeos — Fri, 31 Jul 2026 12:37:43 +0000

Using Laravel internally does not make a CMS a natural fit for every Laravel application. The integration model matters more.

PagibleAI, Statamic and October CMS all use Laravel, but they ask developers to work in different ways.

Statamic is a content-first CMS centered on flat-file and Git workflows. October CMS is a website platform built around Twig, themes and plugins. PagibleAI is a modular CMS package designed to live inside an existing Laravel application.

For a content-led marketing site, that difference may be small. For a SaaS product, customer portal, marketplace or multi-tenant application, it can determine whether the CMS simplifies the architecture or becomes another architecture beside it.

For projects where Laravel is the product rather than an implementation detail, PagibleAI is often the most direct fit.

Architecture at a glance

Decision	PagibleAI	Statamic	October CMS
Product shape	Composer package inside a Laravel app	Full Laravel CMS, installable standalone or into Laravel	Full CMS platform built on Laravel
Default content model	Database-backed Eloquent models	Flat files, with database options available	Database-backed Tailor records and plugin models
Frontend choices	Blade themes or read-only JSON:API	Antlers/Blade or paid Pro REST and GraphQL APIs	Twig themes; custom APIs through CMS pages or PHP routes
Publishing	Drafts, immutable versions, history and scheduling	Revisions, drafts and history in paid Pro	Tailor entries support drafts; wider workflows are project-specific
Automation	Built-in editorial AI and 33 MCP tools	Addons and custom Laravel integrations	Plugins plus AI-oriented developer tooling
Licensing	MIT, no per-site fee	Free Core; paid Pro required for teams, revisions, multisite and headless	A production license is required; one complimentary license is available
Best fit	Laravel products that need an integrated CMS	Content-centric sites and Git-first teams	Theme- and plugin-driven website development

The relevant question is how closely those defaults match the application you intend to maintain.

Adding the CMS to a Laravel application

PagibleAI installs with Composer and two Artisan commands:

composer require aimeos/pagible
php artisan cms:install
php artisan migrate

It uses the Laravel application you already have: its service container, database connections, Eloquent models, authentication, middleware, cache, filesystem and deployment process. The CMS does not require a separate content service or a parallel user system.

Its core records, including pages, reusable elements, files and versions, are normal Eloquent models. CMS content can therefore participate in the rest of the product.

Because Page is an Eloquent model, a controller can retrieve CMS content with ordinary Laravel code:

use Aimeos\Cms\Models\Page;

$page = Page::query()
    ->where('path', 'account/help')
    ->where('status', '>', 0)
    ->access(request()->user())
    ->firstOrFail();

return view('account.help', compact('page'));

The model's global scope selects the active tenant, while access() applies the visitor's page-access rules. Product plans, middleware and application events can interact with the same model. There is no client SDK or synchronization layer between the CMS and the application.

Statamic can also be installed into an existing Laravel application. Its documentation explains that the package installation begins without the content and views supplied by a standard Statamic site, and that content remains flat-file by default. That works when content belongs in Git. It is less natural when content belongs to database-backed product workflows.

October CMS takes a different approach. Its plugin system introduces October-specific conventions: plugin registration files, CMS components, backend controllers, Twig themes and its own extension lifecycle. The team is building an October application powered by Laravel, rather than adding a CMS-shaped module to an otherwise conventional Laravel product.

Content storage and versions

Statamic's flat-file model puts content and configuration in Git, where they can be reviewed in pull requests and deployed with code. That workflow suits documentation sites and developer-led publications.

That model is a less direct fit when editors publish continuously, many tenants share an installation, or content is related to application data.

PagibleAI stores structured content in the database and gives every CMS model a tenant boundary. Editors work on the latest version while visitors receive the published version. Each save creates an immutable snapshot, making comparison, restoration and scheduling parts of the same data model.

The database-first design supports SQLite, MySQL, MariaDB, PostgreSQL and SQL Server. PagibleAI's Laravel Scout integration uses each database's full-text search facility, so a project can begin without a separate search service.

October CMS also uses database content. Its Tailor feature turns YAML blueprints into backend forms and database tables, and its plugin models are based on Eloquent. October fits projects where those blueprints, backend screens and website components define the application. PagibleAI fits cases where CMS content must coexist with an application whose domain model already exists.

Editorial and public APIs

PagibleAI separates editorial operations from public delivery.

Its Lighthouse-based GraphQL API serves the Vue administration interface and custom management tools. Its public JSON:API is read-only and returns published content to SPAs, mobile apps, static-site generators or other services. Blade remains available when server-rendered pages are the simpler answer.

A public frontend does not need administrative mutations, while an editorial client is not constrained by an API designed for anonymous traffic. Both APIs use the same content, permissions and publication state.

Statamic provides REST and GraphQL APIs, but they are Statamic Pro features. As of July 2026, Statamic lists Pro at $349 per site, including one year of updates, with subsequent updates priced separately. The license also covers its control panel, developer support and additional Pro features. Headless delivery, multiple editors, revisions and multisite support therefore belong to the commercial decision.

October CMS documents how to build API endpoints with CMS pages or PHP routes. This leaves more of the public content contract to the project. PagibleAI provides a standardized, read-only content API from the start.

AI and MCP permissions

AI-assisted editing is useful only when generated changes follow the same permissions, tenant boundaries and publication rules as changes made by an editor.

PagibleAI includes tools for drafting and refining text, generating and editing images, transcription, translation and SEO assistance. These features are optional: the CMS works without configuring a model provider.

PagibleAI also exposes 33 content-management tools through MCP. An authorized assistant can search pages, inspect the page tree, create a draft, update reusable elements, manage media, translate content and schedule publication.

Each MCP operation uses the authenticated user's permissions and tenant. Changes create drafts, publication remains explicit and version history provides recovery. The MCP client uses the existing publishing system rather than writing around it.

Statamic and October CMS can both be connected to AI services through addons or custom Laravel code. October 4.3 also introduced AI-oriented development tooling. The difference is that editorial AI and assistant-driven CMS operations are part of PagibleAI's core product design.

Deployment

PagibleAI follows Laravel's contracts for storage, caching, queues and broadcasting. A local installation can use SQLite and local files; production can move media to object storage, locks and caching to Redis, and jobs to dedicated workers without changing the content model.

Existing Laravel monitoring, backups and deployment practices still apply. PagibleAI also supports Octane workers, tenant-scoped content, multiple page trees and domains, endpoint rate limits and content sanitization. These features become relevant as an installation grows beyond one site.

Statamic and October CMS

Statamic: Git-centered content with Pro licensing

Statamic combines flat-file content, a control panel, configurable field types, live preview and Git automation. This suits documentation, publications and marketing sites where developers review content in Git. Pro editon adds developer support and access to its addon ecosystem.

The flat-file default fits database-backed, multi-tenant products less naturally, and installation inside an existing Laravel app needs extra setup. Multiple users, roles, revisions, multilingual and multisite support, REST and GraphQL require the $349-per-site Pro edition. That adds cost when the application only needs an integrated CMS module.

October CMS: a site platform with its own conventions

October CMS combines Twig themes, CMS components, Tailor blueprints and a plugin marketplace. It supports structured content, custom backend screens and Eloquent-based models for custom PHP. Its production license includes platform support.

Adopting October means adopting its plugin lifecycle, backend controllers and Twig conventions. Public API endpoints are project code rather than a standardized content-delivery API. Each website needs a production license after the complimentary license, and continued updates require annual renewal. It fits projects built around October more directly than existing Laravel products needing a CMS module.

When PagibleAI fits

PagibleAI keeps the CMS inside the Laravel application. It supplies structured content, media, page trees, versions, permissions, scheduling, search, delivery APIs and editorial automation. The application retains its domain rules, users, infrastructure and deployment, without a per-site CMS fee or mandatory frontend framework.

This model suits SaaS products with customer-specific content, marketplaces and portals that connect editorial content to application data, and agencies running several sites or domains from one installation. The same published content can serve Blade templates, web applications and mobile clients. AI-assisted editing remains subject to the ordinary publishing controls.

Statamic fits Git-centered content projects, while October CMS fits projects built around its website platform. PagibleAI fits teams that want the CMS to remain a Laravel component.

For developers who already use Laravel as the product foundation, PagibleAI CMS is the most direct option of the three. The PagibleAI source code and Laravel CMS installation guide cover the next steps.

PagibleAI: A Cloud-Native Laravel CMS, Not Just a Container

Aimeos — Thu, 23 Jul 2026 12:09:18 +0000

A container changes how software is packaged. It says little about where that software keeps state or how it behaves when another instance comes online.

A CMS that writes uploads to local disk, caches pages inside one process and runs background work during web requests is still tied to one machine, however neatly it has been containerized.

The Cloud Native Computing Foundation defines cloud-native systems in terms of scalability, loose coupling, resilience, manageability and observability. It cites containers and microservices among the techniques used to achieve those properties.

PagibleAI CMS follows that model through Laravel's infrastructure contracts. Database connections, filesystem disks, cache stores, queues and broadcasting form the boundary between the CMS and the machine running it.

A site can begin with SQLite and local files, then move to replicated application nodes, a managed database, object storage, shared cache and independent queue workers without altering its content model.

“Fully cloud-native” here means that the CMS has no architectural dependency on a particular web server. Kubernetes is one possible runtime, not a requirement.

One application, one operating model

PagibleAI installs as a Composer package:

composer require aimeos/pagible
php artisan cms:install
php artisan migrate

Installation turns an existing Laravel application into the CMS. It does not introduce a separate content service with its own authentication, deployment and monitoring model.

PagibleAI uses the application's service container, Eloquent connections, authentication, middleware, filesystem disks, cache stores, queues and logging channels. Development and operations stay within the Laravel stack.

Laravel serves as both the framework beneath the admin panel and the infrastructure abstraction layer.

Clients → CDN → Load balancer → Laravel replicas
                                  ├── Managed database
                                  ├── Redis cache and locks
                                  ├── Object storage
                                  └── Queue broker → workers

The same topology can run on AWS, Google Cloud, Azure, Kubernetes, conventional virtual machines or a managed Laravel platform. Provider-specific details remain in Laravel's configuration.

Durable state stays off the web node

Horizontal replication only works when the next request can land on any node. PagibleAI keeps durable state in shared infrastructure rather than in the web process.

Content in the database

Pages, reusable elements, files and versions are Eloquent models. PagibleAI supports SQLite for a compact local installation and MySQL, MariaDB, PostgreSQL or SQL Server for production deployments.

Every edit creates an immutable version snapshot. Editors work against the latest version while visitors receive the published one. Any replica can serve either view because the database, rather than the PHP process, owns that state. Laravel's read/write connections can place a managed primary and replicas behind the same CMS connection without introducing another database layer.

Media on a filesystem disk

PagibleAI sends uploads through Laravel's filesystem abstraction. The default public disk is convenient on a laptop, while CMS_DISK=s3 can move the same media operations to Amazon S3 or another S3-compatible service. Laravel's filesystem drivers also cover services such as Cloudflare R2, MinIO and DigitalOcean Spaces.

Uploaded media is then independent of the web-container lifecycle. Replacement nodes need no copied volume, and a CDN can serve files without routing every byte through PHP.

Cache and coordination

PagibleAI's public page cache stores complete HTML responses. In a multi-node deployment, that cache moves from the default file store to a shared, lock-capable store such as Redis.

The lock matters as much as the cached HTML. When a popular page expires, one renderer acquires the lease. Other requests can receive the stale entry during a short revalidation window instead of repeating the same query and rendering work across every replica.

Fresh responses carry shared-cache directives such as s-maxage, allowing a CDN to absorb public traffic before it reaches the application. Requests with a Laravel session or an Authorization header bypass the public cache, so authenticated content is not accidentally promoted to a shared response.

After a publication, deletion or access change commits, PagibleAI queues targeted invalidation work. If that job is delayed, the configured cache lifetime determines how long an old response can remain available.

Commit first, then distribute

Database writes and distributed side effects fail independently. An event emitted before commit may describe a change that later rolls back; a cache or search job may run after a temporary queue failure.

PagibleAI starts these side effects after the database transaction commits:

Search reconciliation is dispatched only after the content transaction succeeds.
Rendered-page invalidation is requested after commit and handled by a queue worker.
Collaboration events are emitted after commit, so another editor never receives a change that the database later rejects.

Clients, caches and search indexes therefore do not observe writes that the database later rejects.

The jobs use Laravel's queue contract, so production can use Redis or Amazon SQS while development stays on a simpler connection. Workers scale independently from the web tier, with Laravel supplying retries, failed-job handling, supervision and deployment restarts.

Built-in search, external engine optional

PagibleAI's Laravel Scout engine uses the full-text facilities already present in the selected database:

FTS5 on SQLite
MATCH ... AGAINST on MySQL and MariaDB
tsvector on PostgreSQL
CONTAINSTABLE on SQL Server

Draft and published content receive separate index rows, preserving the same visibility boundary used by the CMS.

The first production deployment therefore needs no separate search cluster. If a later workload justifies an external engine, Laravel Scout remains the extension point.

Headless and server-rendered delivery

Content is available through three delivery surfaces:

A GraphQL administration API, used by the Vue editor and available to custom tools
A read-only JSON:API for web applications, mobile clients and static-site pipelines
Server-rendered Blade themes for sites that benefit from direct HTML delivery

All three use the same content model. The editor and GraphQL endpoint can remain inside a private application network, the read-only API can sit behind an API gateway, and Blade output can be cached at the edge. Frontend delivery can scale independently without maintaining a second copy of editorial data.

Tenant context beyond the HTTP request

PagibleAI uses single-database multi-tenancy. CMS models carry a tenant_id, and a global Eloquent scope limits queries to the active tenant. Multi-domain routing can map separate page trees to separate domains.

Search jobs retain the tenant they were created for. Page-cache keys include the tenant and domain. Realtime channels require both a matching tenant and the relevant view permission.

That gives SaaS products and agencies one deployment and one shared database with application-level content isolation. It is not database-per-tenant isolation. Requirements that mandate a separate database for every customer need a different tenancy architecture.

Realtime and long-running processes

When broadcasting is enabled, PagibleAI uses Laravel Reverb and Echo to notify other editors about saved, published, restored, moved or deleted content.

The events carry the metadata needed to update a list. They do not turn the WebSocket connection into a second content-delivery API. An open detail view re-fetches changed content through GraphQL, and a client reloads its state after reconnecting because it may have missed events while the socket was unavailable.

Laravel Octane and queue workers keep the application alive between requests or jobs. PagibleAI binds tenant and access state to scoped lifetimes, keeps GraphQL metadata on the request, and avoids a global user-ID permission cache. This prevents state from one execution leaking into the next under Octane.

Optional Pulse metrics cover page requests, search, contact forms, JSON:API, GraphQL and MCP operations. Structured watch logs use the application's logging stack, while Laravel's health route can feed a load balancer or Kubernetes probe.

Configuring a distributed deployment

PagibleAI's local defaults suit a single process. A distributed deployment replaces the node-local parts with shared services.

Concern	Small installation	Distributed installation
Content	SQLite	Managed MySQL, MariaDB, PostgreSQL or SQL Server
Media	Local public disk	S3-compatible object storage and CDN
Page cache and locks	File cache	Shared Redis cache
Sessions	Local or database	Shared database or Redis
Jobs	Synchronous or database queue	Redis or SQS with independent workers
Web runtime	One PHP process	Replicas behind a load balancer
Live updates	Disabled	Reverb with shared production configuration
Telemetry	Local logs	Centralized logs and optional Pulse metrics

A production environment may begin like this:

DB_CONNECTION=pgsql
CACHE_STORE=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis

CMS_DISK=s3

# After installing and configuring Laravel Reverb
CMS_BROADCAST=true

The complete-page cache selects its own store, so configure Redis explicitly for production:

// config/cms/theme.php
'cache' => env('APP_DEBUG') ? 'array' : 'redis',

The infrastructure also needs a few standard operating rules:

Build application code, Composer dependencies and published assets into an immutable release.
Keep uploaded media off ephemeral web disks.
Run queue workers separately, restart them during deployments and run only one scheduler.
Ensure the CDN bypasses public HTML caching for session and authorization requests.
Extend Laravel's health endpoint with database and cache diagnostics appropriate to your availability target.

PagibleAI uses Laravel's cache API, queues and filesystem directly, so the same operational tooling applies to the CMS and the rest of the application.

The source is available in the PagibleAI GitHub repository, and the installation guide covers the first deployment.

What PagibleAI leaves to the deployment

PagibleAI does not provision a VPC, tune PostgreSQL, choose a Redis topology or write Kubernetes manifests. The deployment team owns those choices.

They remain deployment responsibilities. PagibleAI keeps them outside the content model and editorial workflow, allowing state to move to managed services, workers to split from the web tier and public responses to move toward the edge.

The visible product includes structured content, versioning, AI-assisted editing, GraphQL, JSON:API and MCP tools. The deployment model rests on less visible choices: authoritative database state, replaceable storage, shared cache coordination, post-commit side effects, queued work and request isolation in long-running processes.

The same PagibleAI CMS package and content model can run in one process or across a cluster.

How to customize Aimeos e-commerce projects without maintaining a fork

Aimeos — Tue, 21 Jul 2026 11:28:22 +0000

Editing a file under vendor/ can solve today's problem and create the next upgrade's problem.

The first change usually looks harmless: move a block on the product page, add a checkout rule, adjust the way products are loaded. After a few more, the shop depends on a private fork and every Composer update begins with a three-way diff.

Aimeos provides a separate place for each kind of change. Wording can stay in translation configuration, page composition in page configuration, markup in a template and business rules in decorators. Larger features can live in their own Composer package.

When a new requirement arrives, start by finding the narrowest layer that can handle it.

Choose the smallest extension point

Before writing a class, identify the layer that owns the requirement.

Requirement	Use
Change a label, page size or feature switch	`config/shop.php`
Add or remove a storefront component	page configuration
Change the Laravel page shell	an overridden Blade view
Restyle the shop	a custom theme
Change component markup	a template override
Store project-specific product data	properties or attributes
Add behavior around existing logic	a decorator
Replace an implementation completely	a configured class replacement
Add new storage, behavior or an integration	a project-specific Aimeos extension

Use the first row that solves the problem. There is little value in creating a subclass for a configuration change or copying a controller when a decorator can add the required behavior. Related project code is also easier to follow when it lives in one extension.

Start with configuration

The Laravel integration exposes the shop configuration in config/shop.php. Its nested arrays follow the structure of Aimeos components and controllers, so the location of a setting identifies the part of the system it affects.

Suppose a store needs 24 products per page, no add-to-basket button in product lists, a two-level mega menu and “Brands” instead of “Suppliers”. The relevant configuration is short:

'client' => [
    'html' => [
        'catalog' => [
            'lists' => [
                'basket-add' => false,
                'size' => 24,
            ],
        ],
    ],
],

'controller' => [
    'frontend' => [
        'catalog' => [
            'levels-always' => 2,
        ],
    ],
],

'i18n' => [
    'en' => [
        'client' => [
            'Suppliers' => ['Brands'],
        ],
    ],
],

No service provider, listener or copied component is involved.

Some structural changes are environment switches. Multi-language routes, vendor-specific sites and seller registration can be enabled without rebuilding the routing layer:

SHOP_MULTILOCALE=true
SHOP_MULTISHOP=true
SHOP_REGISTRATION=true

For many projects, config/shop.php is where customization starts.

Compose pages from components

A storefront page is assembled from components. A product detail page can contain locale selection, the mini basket, category navigation, search, a stage area, the product itself and session-based lists such as recently viewed products.

The list lives in config/shop.php:

'page' => [
    'catalog-detail' => [
        'locale/select',
        'basket/mini',
        'catalog/tree',
        'catalog/search',
        'catalog/stage',
        'catalog/detail',
    ],
],

This version leaves out catalog/session. The page no longer prepares the recently viewed and pinned-product area, but the product-detail component remains untouched.

You can also add an existing component to a page, or create a Laravel route and render the required Aimeos components through the Shop facade.

The Laravel extension guide documents the available page sections, routes and facade integration.

Keep the page shell, markup and theme separate

Aimeos separates presentation into three layers. Blade views define the surrounding Laravel page, component templates generate the storefront markup, and themes provide CSS, JavaScript, fonts and images.

To change the complete product-detail page shell, copy the corresponding package view to the application's vendor-view directory:

resources/views/vendor/shop/catalog/detail.blade.php

Laravel prefers the application copy, leaving the package file untouched.

If the page shell is already correct but the product markup is not, override only the relevant template in the project extension:

templates/client/html/catalog/detail/body.php

An identically named project template takes precedence over the default. A custom image gallery may need only catalog/detail/image.php; it does not require a copy of the entire detail component.

If the HTML structure is already right, a theme is enough. Aimeos keeps assets such as catalog-detail.css and basket-mini.js per component, so pages load the assets for the components they use.

The size of the override matters during upgrades. Replacing image.php instead of body.php, for example, leaves less upstream code to compare.

During development, clear the Aimeos and compiled Blade caches if configuration or template changes do not appear:

php artisan aimeos:clear
php artisan view:clear

The official guides cover both template overrides and custom themes.

Add business rules with decorators

Many project rules only need to run around existing behavior. Typical examples include a regional availability check, an audit event, data from an external service or validation before an item is stored.

A decorator wraps the existing object, changes only the relevant methods and delegates everything else.

For example, a product-controller decorator can check products retrieved individually through get() against an application service owned by the Laravel project:

namespace Aimeos\Controller\Frontend\Product\Decorator;

use App\Commerce\AvailabilityRule;
use Aimeos\MShop\Product\Item\Iface;

final class Availability extends Base
{
    public function get(string $id): Iface
    {
        $item = parent::get($id);

        app(AvailabilityRule::class)->assertPurchasable($item);

        return $item;
    }
}

AvailabilityRule is ordinary Laravel application code. The decorator connects it to the Aimeos product controller.

The class belongs at:

src/Controller/Frontend/Product/Decorator/Availability.php

'controller' => [
    'frontend' => [
        'product' => [
            'decorators' => [
                'local' => ['Availability'],
            ],
        ],
    ],
],

Only get() changes. Product searches, aggregation and the remaining controller API continue through the original implementation. This example therefore guards direct product retrieval only. If the rule determines whether a product may be purchased, enforce it again at basket or checkout level.

HTML clients and data managers support the same pattern. Several decorators can be combined without collecting unrelated rules in one project class.

When the standard behavior is unsuitable, Aimeos factories also support named replacements. Setting controller/frontend/product/name to Project, for example, selects Aimeos\Controller\Frontend\Product\Project. This is useful when a decorator would have to replace most of the original implementation anyway.

Put larger customizations in one package

Once a customization contains several classes, templates, translations or database changes, it should become a project-specific Aimeos extension.

Before extending a core table, check whether the requirement fits an Aimeos property, attribute or related domain item. Much project-specific product data can be stored without changing the core schema.

The standalone distribution already declares packages/* as a Composer path repository. An extension can live there during development and be installed like any other dependency:

composer require acme/shop-extension

A typical project extension contains:

packages/shop-extension/
├── composer.json
├── manifest.php
├── config/
├── i18n/
├── setup/
├── src/
├── templates/
└── themes/

The manifest registers the resources contributed by the package. The setup/ directory carries schema updates, Composer handles autoloading, and the extension can be versioned independently from both Laravel and Aimeos.

For a single shop, this keeps its Aimeos-specific code in one place. Organizations running several shops can use the same package to share an integration, theme or business rule between applications.

The extension documentation explains manifests and package structure, while the extension generator creates the initial files.

Know when to replace the HTML frontend

Template overrides work well while the application still fits the component model. If nearly every page needs replacing, or the same commerce backend must serve web, mobile and in-store clients, the APIs are usually the cleaner option.

Aimeos exposes storefront data through JSON:API and administration through GraphQL. The product, price, stock, basket and order logic can remain in place while a new client replaces the presentation.

A team does not have to make that change all at once. It can keep the working storefront, override a few templates and use the APIs only for channels that need a separate interface.

What the structure costs

The first extension takes some orientation. Configuration paths correspond to class and template paths, and the naming convention is more explicit than a generic Laravel hook.

Once controller/frontend/product/decorators/local has led to the product controller's decorator directory, the same relationship repeats throughout the platform. The paths make it possible to see who owns the behavior and how the project changed it.

Separation does not make custom code immune to upstream changes. Templates, decorators and replacement classes should still be reviewed during major upgrades, but the affected surface is explicit and confined to the project extension.

Upstream code stays in vendor/, project code stays in the project extension, and updates require a focused compatibility review rather than a source-code merge.

Each kind of change has an obvious home. By using the narrowest one that fits, a shop can move a long way from the Aimeos defaults without becoming a fork.

PagibleAI: The Best Headless CMS for Laravel

Aimeos — Thu, 16 Jul 2026 11:23:33 +0000

Headless is supposed to loosen the frontend. Too often, it merely moves the constraint somewhere else.

A hosted platform places content behind a remote service. A toolkit leaves the delivery API and publishing model to the application. An admin framework can turn a headless project into a CMS development project before the frontend has even begun.

PagibleAI CMS keeps the content system inside Laravel, exposes published material through a standard API and leaves the frontend entirely open.

Structured content, reusable elements, media, drafts, immutable versions and scheduled publishing are already part of the package.

The CMS remains part of the application

PagibleAI installs into an existing Laravel project:

composer require aimeos/pagible
php artisan cms:install
php artisan migrate

The CMS does not live behind a vendor account or inside a second application with its own users, permissions and release cycle. It shares the Laravel project’s database, authentication, storage, cache and deployment process.

The frontend is decoupled; deployment and operations remain consolidated.

The useful boundary in a headless system lies between content and presentation, not between a Laravel application and its own content.

A remote CMS can be the right decision when outsourcing infrastructure is the priority. It is less persuasive when the project already has a capable application platform and the additional service creates another place where business rules must be translated, synchronized and monitored.

What the package already settles

Several decisions precede the first frontend request. PagibleAI makes them explicit:

Concern	PagibleAI’s answer
Public delivery	Read-only JSON:API
Editorial operations	Administrative GraphQL API
Content model	Pages, reusable elements, files and versions
Publishing	Drafts, scheduling, history and restoration
Site structure	Hierarchical page trees for navigation
Frontend	Any API client, with Blade available when useful
Reach	Multiple domains and languages
Search	Full-text search through Laravel Scout
Ownership	Open source and self-hosted
Automation	Optional AI tools and an MCP interface

PagibleAI documents this separation between editorial operations and public delivery in the PagibleAI headless CMS guide.

Editors manage versions and reusable content through one publishing system, while frontends receive a stable stream of published material. You extend the CMS instead of finishing its foundations.

The Laravel alternatives

The Laravel shortlist usually includes Statamic, Twill and Filament. The practical difference is how much work remains after installation.

Option	Best suited to	What remains
PagibleAI	Most headless Laravel applications	All included
Statamic	Teams wanting a mature commercial CMS and paid support	A Pro license for headless features
Twill	Bespoke editorial systems with custom models	The public delivery API
Filament	Custom back offices and administration tools	The CMS itself

Statamic offers a control panel, REST and GraphQL, but requires a paid Statamic Pro license for headless delivery and multi-user publishing.

Twill supplies editorial components and flexible content modules, while leaving frontend routes and API endpoints to the developer.

Filament provides CRUD interfaces for Eloquent models; publication states, versions, previews and content delivery remain your own concerns.

PagibleAI is the only option in this group that combines a complete open-source CMS with a built-in public delivery API - without a paid headless tier or a custom delivery layer.

A deliberate boundary between editing and delivery

The public and editorial APIs have different roles:

GraphQL serves the administration layer, where editors and custom tools need precise queries, relationships and mutations
Public frontends receive published content through a high performance read-only JSON API following the JSON:API standard.

The delivery API has a narrow promise: return content that is ready to be shown. A frontend does not need to interpret editorial permissions or infer whether a record is still a draft. The public contract stays read-only and editorial complexity remains behind GraphQL.

The choice of frontend belongs to your project. Nuxt, React, VueJS, a native application or another service can consume the same published content. If parts of the site is better served directly by Laravel, Blade remains available without requiring a second content system.

Headless delivery becomes a choice of presentation, not a demand to split every project into separate applications.

Content that survives the current frontend

A headless CMS should preserve structure without smuggling presentation into the content.

PagibleAI separates pages, reusable elements, files and versions. A product statement, author profile, legal notice or call to action can be maintained once and placed wherever it belongs. Each frontend decides how to present it.

An editor can update a product statement once and publish it. The same approved version then becomes available to a Nuxt storefront, a mobile application and a customer portal, while each frontend controls its presentation.

The page tree supplies hierarchy for navigation, while shared elements remain reusable beyond an individual page. Editors retain a coherent view of the site without binding its content to one template system.

That separation also governs publishing. Every editorial save creates a snapshot. Editors work with the latest version; public consumers continue to receive the published one. A replacement can be reviewed, scheduled or discarded without disturbing the live experience.

When several frontends depend on the same CMS, this separation becomes essential. Publication is decided once, at the source, rather than interpreted independently by every consumer.

The unglamorous work is already done

The attraction of building a CMS from smaller Laravel components is strongest at the beginning. A model, migration and administration form can be produced quickly.

The expensive work comes later: search, restoration, media relationships, translations, page movement, safe previews, publication scheduling and API compatibility.

PagibleAI treats those concerns as part of the product:

Full-text search works with SQLite, MySQL, PostgreSQL and SQL Server
Multiple domains and languages can share one installation
Tenant-scoped content supports projects operating several sites from the same Laravel deployment.

None of these capabilities is especially fashionable but all of them become expensive when discovered late.

PagibleAI also includes optional AI-assisted editing and a full MCP interface, but neither is required for the headless publishing workflow.

The PagibleAI feature overview documents these capabilities in greater detail.

Where PagibleAI may not be the answer

It is self-hosted and your team operates it as part of the Laravel application.

If the primary requirement is to hand the entire CMS operation to a vendor, a managed platform is the more natural choice.
Public delivery is centred on JSON:API for performance and scalability reasons, while GraphQL serves editorial work. A project committed specifically to a public GraphQL content API would need to add that layer.
Multi-tenancy uses a shared database. Applications requiring a separate database for every tenant fall outside the intended model.

For most Laravel teams seeking a self-hosted headless CMS, the trade is still favourable: the content and publishing system arrives complete.

A better use of development time

The real cost of a headless CMS is the engineering it diverts from the product.

PagibleAI handles content structure, editorial workflow and publication state. Your team shapes the frontend, its design, interactions, performance and relationship with the rest of the application.

Editors get a dependable publishing environment, frontends consume consistent published content, and developers decide how that content becomes a product. The CMS stays close to Laravel without tying the presentation to it.

The PagibleAI source code is available on GitHub.

For a Laravel team that wants a headless CMS without also building one, PagibleAI is the strongest option.

Frequently asked questions

What is PagibleAI CMS?

PagibleAI CMS is an open-source, self-hosted headless CMS for Laravel. It provides structured content, reusable elements, media management, drafts, immutable versions, scheduled publishing and public content delivery within an existing Laravel application.

Is PagibleAI a headless CMS?

Yes. PagibleAI separates content management from presentation. Editors manage content through the administration interface, while websites, mobile applications and other clients retrieve published content through a read-only JSON:API.

Does PagibleAI require a separate hosted service?

No. PagibleAI runs inside your Laravel application and uses its database, authentication, storage, cache and deployment infrastructure. Content does not need to be stored in a separate vendor-controlled platform.

Which frontends can use PagibleAI?

Any frontend capable of consuming an HTTP API can use PagibleAI. Common choices include Nuxt, Vue, React, native mobile applications and external services. Laravel projects can also render selected pages with Blade.

Which APIs does PagibleAI provide?

PagibleAI provides two APIs with distinct responsibilities. Its read-only JSON:API delivers published content to public frontends. Its GraphQL API supports editorial administration, including content queries, relationships and mutations.

How does publishing work in PagibleAI?

Each editorial save creates an immutable version. Editors can review, restore or schedule versions without immediately changing the public content. Frontends continue to receive the currently published version until a replacement is published.

Can content be shared between multiple frontends?

Yes. Pages, reusable elements and files are stored independently of a particular frontend. The same published content can therefore supply a website, mobile application, storefront or customer portal while each client controls its own presentation.

Does PagibleAI support multiple websites and languages?

Yes. One installation can manage content for multiple domains and languages. It also supports tenant-scoped content for applications that operate several sites from one Laravel deployment using a shared database.

How is PagibleAI different from Filament or Twill?

Filament is an administration framework rather than a complete CMS, so content versioning, publishing workflows and delivery APIs must be implemented separately. Twill provides editorial components and flexible content modules but leaves public routes and API delivery to the application. PagibleAI includes both the publishing system and a public content API.

How is PagibleAI different from Statamic?

Both products can support headless Laravel projects. Statamic is a commercial CMS whose headless and multi-user capabilities require a Pro license. PagibleAI is open source and includes headless content delivery without a paid tier.

Aimeos: The Headless E-Commerce Framework for Laravel

Aimeos — Sat, 04 Jul 2026 16:58:52 +0000

Laravel developers rarely need help building a storefront. Given a familiar stack, they can ship one with Blade, Livewire, Vue, React, Next.js, Nuxt, or a mobile client without much ceremony. The harder question is what happens after the first version is live, when the business starts asking for regional catalogs, customer-specific prices, subscriptions, stock rules, marketplace workflows, imports, exports, payment integrations, and an admin experience that non-developers can use every day.

That is the point where many lightweight e-commerce packages begin to show their limits. They are pleasant while the model is simple, but the custom code around them grows quickly once the shop becomes central to the business, which is why Aimeos should be the default starting point when e-commerce is expected to become a serious part of a Laravel application rather than a small feature beside it.

Aimeos approaches the problem from the stronger direction: it gives Laravel a mature e-commerce engine first, then leaves the presentation layer open.

Aimeos is not just a cart, a product table, and a checkout flow. It brings catalog management, basket handling, checkout, orders, customers, stock, suppliers, services, subscriptions, scheduled jobs, imports, a full administration interface, a JSON REST API for storefronts, and a GraphQL API for administration. More importantly, it does all of this without forcing Laravel to disappear behind a separate platform.

That makes Aimeos the clearer favorite for ambitious Laravel e-commerce projects. Lunar PHP and Laravel Shopper both have useful places in the ecosystem, but Aimeos is the one that starts with the broader e-commerce model, the operational admin, the APIs, and the growth path already in place.

To install the Aimeos headless distribution, use:

composer create-project aimeos/aimeos-headless aimeos

The Short Version

Layer	Responsibility
Laravel	Application structure, routing, authentication, sessions, cache, logging, mail, queues, policies, and deployment
Aimeos	Catalog, prices, stock, basket, checkout, orders, services, subscriptions, jobs, imports, APIs, and administration
Storefront	Blade, Livewire, Vue, React, Next.js, Nuxt, mobile apps, partner portals, or any other client

That division is the real argument for choosing Aimeos first. Laravel remains the application, Aimeos becomes the e-commerce engine, and the frontend can evolve without turning every business rule into custom application code.

Laravel Remains The Application, Not The Shopping Cart

The best part of Aimeos in a Laravel project is not only the feature set, but the boundary it draws. Laravel continues to own the application structure: routing, authentication, sessions, cache, logging, configuration, mail, queues, policies, and deployment. Aimeos takes responsibility for the e-commerce domain, where product data, prices, baskets, stock, orders, services, and subscriptions need a model that has already survived real complexity.

That separation is what makes Aimeos especially suitable for headless e-commerce. The storefront can change without rewriting the engine beneath it, while the e-commerce layer remains deep enough for the business requirements that usually arrive later. A team can start with a conventional Laravel storefront and still have a path toward a PWA, a mobile app, a B2B portal, a marketplace frontend, or partner-facing API clients.

Laravel application
    -> routing, auth, cache, sessions, queues, mail, policies

Aimeos e-commerce engine
    -> catalog, prices, stock, basket, checkout, orders, admin

APIs
    -> JSON:API for storefronts
    -> GraphQL for administration

Clients
    -> Blade, Livewire, Vue, React, Next.js, Nuxt, mobile

This may sound simple, but it is exactly the division many e-commerce projects fail to protect.

Headless Without An Unfinished Back Office

Headless e-commerce is often described as frontend freedom, although that framing leaves out the part that matters most in production. A custom storefront is only useful if the people running the business can still manage products, prices, orders, content, stock, and customer data without waiting for developers to edit database rows or build internal tools from scratch.

Aimeos avoids that trap because its headless APIs sit beside an existing administration system rather than replacing it.

Aimeos part	Why it matters in a headless setup
JSON REST API	Custom storefronts can work against the e-commerce engine without being tied to one frontend stack
GraphQL admin API	Administration and automation can access shop data through a structured API
Standard admin	Operations teams still have a usable interface for daily work
Jobs and imports	Product data, stock updates, and scheduled processes do not have to be invented around the edges

That balance is one of the main reasons Aimeos feels different from thinner Laravel e-commerce packages. It treats the frontend as replaceable, but it does not treat the e-commerce operation as an exercise left to the application team.

Built For The Moment The Shop Becomes A Platform

A simple store can survive on a simple package, and there is nothing wrong with that. The reason to choose Aimeos is that many Laravel e-commerce projects do not stay simple for very long. A brand expands into multiple regions, a B2C shop gains B2B accounts, one catalog becomes several catalogs, a single seller model becomes a marketplace, or the product data grows large enough that imports, indexing, and caching become architectural concerns rather than background tasks.

That is where Aimeos starts to pay for its additional depth:

multi-site setups where one installation serves several channels or regions
B2B projects with customer-specific prices, visibility, or ordering behavior
marketplace models where vendors, products, orders, and payments need clearer boundaries
subscription-oriented projects where recurring processes must be part of the e-commerce model
large catalogs where indexing, imports, caching, and operational tooling matter early

Aimeos is built for those situations. Its multi-site capabilities, broad e-commerce model, marketplace and B2B orientation, subscription support, import and job infrastructure, and scaling options make it the stronger foundation for projects where e-commerce is not an add-on feature but the system the business depends on.

The tradeoff is that Aimeos has more concepts to learn than a smaller package. That is not a weakness if the project is expected to grow, because the complexity exists either way; the choice is whether it lives in a framework designed for e-commerce or in custom application code that accumulates around a package that was never meant to carry that much responsibility.

Why Aimeos Comes Out Ahead Of Lunar PHP And Laravel Shopper

Lunar PHP and Laravel Shopper are both useful Laravel e-commerce projects, but they are narrower choices. The practical question is not whether they can work, because they can, but whether they give a Laravel team enough e-commerce depth before the business starts asking for more complex catalogs, B2B rules, marketplace behavior, subscriptions, imports, operational tooling, and multiple storefronts.

Framework	Best fit	What stands out	Why Aimeos is favored
Aimeos	Larger e-commerce platforms, B2B, marketplaces, multi-site setups, complex catalogs, and projects expected to scale	A mature e-commerce engine with APIs, admin, jobs, imports, subscriptions, and operational depth	It is the strongest default when e-commerce is core to the business
Lunar PHP	Custom Laravel stores where an Eloquent-first development style is the priority	A familiar Laravel feel with clean developer experience	Aimeos gives more platform depth when requirements move beyond a custom store
Laravel Shopper	Existing Laravel apps that need package-style e-commerce building blocks	A Laravel-friendly, Filament-based approach with swappable models and composable packages	Aimeos is stronger when the project needs a complete e-commerce engine instead of building blocks

Lunar PHP is attractive when the development team wants the e-commerce layer to feel as close to Laravel conventions as possible. Its Eloquent-first model and Laravel-native style make sense for teams that want a custom store and expect to shape more of the surrounding business logic themselves, although that strength becomes a limitation when the project needs broader platform behavior rather than a Laravel-shaped e-commerce package.

Laravel Shopper is appealing from a different angle. It is package-oriented, uses familiar Laravel ecosystem tools, and fits teams that want to add e-commerce capabilities to an existing application without adopting a heavier e-commerce platform, although Aimeos is the stronger option when the e-commerce layer should become durable infrastructure instead of a set of adaptable building blocks.

Aimeos is the clearer favorite when the e-commerce system itself needs depth from the beginning. If the roadmap includes B2B rules, multiple storefronts, marketplace behavior, subscriptions, large imports, operational administration, or very large catalogs, Aimeos gives the Laravel team more of the foundation upfront rather than asking them to build it later.

The Practical Case For Aimeos

The strongest argument for Aimeos is not simply that it is headless, because many tools can make that claim. The stronger argument is that Aimeos combines headless flexibility with a serious e-commerce core, a working admin, Laravel integration, and enough architectural room for projects that become more demanding over time.

Choose Aimeos when the shop is expected to become a platform,
and treat smaller packages as niche choices for simpler stores.

That combination is difficult to replace. A thin package may feel faster at the beginning, while a hosted platform may remove too much control from a Laravel team that wants to own its application. Aimeos occupies the strongest middle ground: it gives Laravel developers a real e-commerce framework without taking away the freedom to build the customer experience in the stack that suits the product.

For small stores, Aimeos may be more power than necessary. For ambitious Laravel e-commerce projects, especially those likely to move into B2B, marketplace, multi-site, subscription, or high-volume catalog territory, that power is exactly the reason Aimeos should be the preferred choice.

Aimeos Prisma 0.5: a sturdier PHP layer for AI providers

Aimeos — Tue, 30 Jun 2026 10:11:09 +0000

Most AI integrations do not fail because the first provider is hard to call. They become awkward later, when the application has to speak several dialects at once.

One endpoint generates text. Another returns embeddings. A third handles transcription. Image generation arrives with its own payload shape, its own errors, and its own idea of metadata. Add web search, tool calling, local models, or an OpenAI-compatible gateway, and the useful application code starts to disappear behind provider plumbing.

Aimeos Prisma exists to keep that boundary small. It gives PHP applications one API across text, image, audio, and video providers, while still leaving room for provider-specific options when they are needed.

The 0.5 release makes that layer more suitable for real applications: streamed responses, conversation history, stronger schema support, request observation, better test doubles, safer response handling, and more provider coverage.

composer require aimeos/prisma

The API shape

Prisma is a framework-agnostic PHP 8.2+ package. It is MIT-licensed, uses Guzzle internally, and keeps the calling pattern consistent across provider types.

use Aimeos\Prisma\Prisma;

$text = Prisma::text()
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->write('Summarize the benefits of renewable energy')
    ->text();

$image = Prisma::image()
    ->using('stabilityai', ['api_key' => getenv('STABILITYAI_API_KEY')])
    ->imagine('a clean product photo of a ceramic coffee cup')
    ->binary();

$transcript = Prisma::audio()
    ->using('deepgram', ['api_key' => getenv('DEEPGRAM_API_KEY')])
    ->transcribe($audioFile)
    ->text();

$description = Prisma::video()
    ->using('gemini', ['api_key' => getenv('GEMINI_API_KEY')])
    ->describe($videoFile)
    ->text();

The provider name changes. The surrounding application shape does not.

Streaming belongs in the core API

For user-facing tools, waiting for a full model response is often the wrong interaction. Prisma 0.5 adds stream() as a text capability instead of treating it as a separate integration path.

use Aimeos\Prisma\Prisma;

$response = Prisma::text()
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->ensure('stream')
    ->stream('Write a short launch announcement for our PHP package');

foreach ($response->stream() as $delta) {
    echo $delta;
}

$full = $response->output();
$usage = $response->usage();

Streaming keeps the same configuration surface as write(): model selection, system prompts, tools, prior messages, and provider options all travel through the same provider object.

In Laravel, it can be handed directly to response()->eventStream():

use Aimeos\Prisma\Prisma;
use Illuminate\Support\Facades\Route;

Route::get('/chat', function () {
    $response = Prisma::text()
        ->using('openai', config('services.openai'))
        ->ensure('stream')
        ->stream('Explain event sourcing in plain English');

    return response()->eventStream(function () use ($response) {
        foreach ($response->stream() as $chunk) {
            if (is_string($chunk)) {
                yield $chunk;
            }
        }
    });
});

There is one operational rule: consume the stream before reading body-derived metadata. Usage, citations, tool steps, finish reason, and response metadata are complete only after the stream has been drained. Rate-limit data from headers is available immediately.

Conversation history without a second abstraction

Chat history now lives in withMessages(). The current prompt passed to write(), stream(), or structure() becomes the next user turn.

use Aimeos\Prisma\Prisma;

$response = Prisma::text()
    ->using('anthropic', ['api_key' => getenv('ANTHROPIC_API_KEY')])
    ->withSystemPrompt('You are a concise technical assistant.')
    ->withMessages([
        ['role' => 'user', 'content' => 'I need a laptop recommendation.'],
        ['role' => 'assistant', 'content' => 'What is your budget and workload?'],
    ])
    ->write('Around 1500 EUR, mostly PHP development and light video editing.');

echo $response->text();

For multimodal providers, user turns can also carry files, subject to each provider's file support.

Structured output is stricter when it can be, explicit when it cannot

Structured output is most useful when the code can state what it expects and then check what it received. Prisma 0.5 improves both sides.

use Aimeos\Prisma\Prisma;
use Aimeos\Prisma\Schema\Schema;

$schema = Schema::for('ticket', [
    'title' => Schema::string()->required(),
    'priority' => Schema::string()->enum(['low', 'normal', 'high'])->required(),
    'tags' => Schema::array()->items(Schema::string()),
]);

$response = Prisma::text()
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->ensure('structure')
    ->structure('Extract a support ticket from: Checkout is broken for EU cards', $schema);

$ticket = $response->structured();

By default, Prisma uses the provider's native structured-output mode when one exists. If a schema is too large or deeply nested for that mode, pass ['mode' => 'json'] and Prisma will embed the schema in the prompt and parse the returned JSON.

$response = Prisma::text()
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->structure('Extract a support ticket', $schema, [], ['mode' => 'json']);

The schema builder also gained unions, reusable definitions, references, and validation:

use Aimeos\Prisma\Schema\Schema;

$schema = Schema::for('order', [
    'billing' => Schema::ref('Address')->required(),
    'shipping' => Schema::ref('Address')->required(),
    'discount' => Schema::anyOf([
        Schema::string(),
        Schema::number(),
    ]),
])->def('Address', Schema::object([
    'street' => Schema::string()->required(),
    'city' => Schema::string()->required(),
]));

$errors = $schema->validate($response->structured());

if ($errors) {
    // reject, retry, or ask for a correction
}

Provider-enforced structured output reduces risk, but it does not make generated content trusted. Validate the shape you receive, and handle generated values as carefully as any user-supplied input.

Wider provider coverage

Prisma 0.5 now covers 29 providers across text, image, audio, and video workflows. The release adds Azure OpenAI text support, VertexAI text support, image generation through xAI, ModelsLab, and Replicate, and text embeddings across more providers.

OpenAI-compatible endpoints remain a practical escape hatch. Local servers, internal gateways, and proxy services can be used through the openai provider by changing the base URL:

$response = Prisma::text()
    ->using('openai', [
        'api_key' => getenv('GATEWAY_API_KEY'),
        'url' => 'https://my-gateway.example.com',
    ])
    ->model('my-model')
    ->write('Hello from an OpenAI-compatible gateway');

Provider tools also behave more carefully in 0.5. Prisma can omit unsupported combinations, such as a server-side tool that a provider cannot use for the current request shape, without forcing every application to know those edge cases.

Observability where the call happens

Production AI calls need accounting. A plain response string cannot tell you which model ran, how long the request took, whether it failed, or what usage the provider reported.

Prisma 0.5 adds request-scoped observers:

use Aimeos\Prisma\Prisma;
use Aimeos\Prisma\Values\Observation;

$response = Prisma::text()
    ->observe(function (Observation $observation) {
        logger()->info('ai.operation', $observation->toArray());
    })
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->model('gpt-4.1-mini')
    ->write('Draft a changelog entry');

An observation records the operation, provider type, provider name, model, duration, error state, usage, and metadata. Streamed responses are observed after the stream completes, so their usage and metadata are present.

Usage and metadata now have names

Provider usage payloads are inconsistent. input_tokens, prompt_tokens, promptTokenCount, and inputTokens may all mean the same thing, depending on which API answered.

In 0.5, usage() returns a Values\Usage object:

$usage = $response->usage();

$usage->promptTokens();
$usage->completionTokens();
$usage->totalTokens();
$usage->cacheReadTokens();
$usage->cacheWriteTokens();
$usage->thoughtTokens();
$usage->used();

meta() returns a Values\Meta object:

$meta = $response->meta();

$meta->id();
$meta->model();
$meta->thinking();
$meta->reasoningDetails();

Both objects remain array-compatible for provider-specific fields:

$rawUsage = $response->usage()->all();
$created = $response->meta()['created'] ?? null;

Existing code that type-hints these results as arrays should switch to Values\Usage, Values\Meta, or call all() when a raw array is required.

Testing without a live provider

Application tests should not need live API keys to prove that the right Prisma calls are made. Prisma 0.5 adds a recording fake:

use Aimeos\Prisma\Prisma;
use Aimeos\Prisma\Responses\TextResponse;

$fake = Prisma::fake([
    TextResponse::fake('Invoice approved')
        ->withUsage(12, ['prompt_tokens' => 5, 'completion_tokens' => 7]),
]);

$result = Prisma::text()
    ->using('openai', ['api_key' => 'test'])
    ->write('Review this invoice')
    ->text();

$fake->assertCalled('write', function (array $args) {
    return str_contains($args[0], 'invoice');
});

Prisma::reset();

For provider-level tests, the new testing helpers can run real provider code against mocked Guzzle responses. Request building, response parsing, streaming, and tool loops can be exercised without leaving the test process.

Responses implement JsonSerializable, which keeps snapshot-style assertions straightforward:

$payload = $response->jsonSerialize();

Safer response boundaries

Provider responses may be streamed, proxied, malformed, or simply too large. withMaxResponseSize() bounds how many bytes Prisma will read from a single provider response:

$response = Prisma::text()
    ->using('openai', ['api_key' => getenv('OPENAI_API_KEY')])
    ->withMaxResponseSize(16 * 1024 * 1024)
    ->write('Analyze this document');

The default limit is 64 MB per provider response. It applies to streamed and non-streamed calls, including individual tool-loop turns.

The release also tightens provider discovery by validating provider type and name before building provider class names.

Custom providers are part of the story

Prisma resolves providers by namespace convention:

Prisma::text()->using('myprovider', $config);

That maps to:

Aimeos\Prisma\Providers\Text\Myprovider

The new custom provider guide documents provider discovery, contracts, response objects, structured output, tool loops, async operations, OpenAI-compatible APIs, and testing.

That is useful when a project has an internal gateway, a private model host, or a provider that Prisma does not ship yet.

Upgrading

The main migration points are small but worth checking. Use stream() for live text responses. Pass prior turns through withMessages(). Call structure() to request structured output; keep using structured() to read the parsed response. Treat usage() and meta() as value objects, or call all() when existing code expects arrays. Drain streamed responses before reading usage, metadata, citations, tool steps, or finish reason. Reset Prisma::fake() in test teardown.

Links

Docs: https://php-prisma.org

GitHub: https://github.com/aimeos/prisma

Custom providers: CUSTOM-PROVIDERS.md

Prisma 0.4 established the broad interface across text, image, audio, and video. Prisma 0.5 makes that interface easier to run in production: streamed UIs, observable calls, cheaper tests, clearer schemas, provider fallbacks, and custom integrations.

How to implement a multi-vendor e-commerce marketplace using Laravel

Aimeos — Thu, 25 Jun 2026 11:09:19 +0000

A marketplace is a multi-tenant system that happens to sell things. That sentence is the whole implementation problem in one line. The seller dashboard looks like the hard part during planning, but the real work shows up around week three, when every query in the system suddenly has to answer a new question. Whose data is this? Which vendor owns this product, this order line, this stock level, this price? The storefront was never the issue. The issue is that a marketplace is multi-tenant from the first table, and most shops are not.

So the first decision you make is also the one that costs the most if you get it wrong: do you build the tenancy yourself, or start from a backend that already has it. Retrofitting isolation onto a single-tenant shop is not a feature you add — it's a rewrite you discover. You thread a vendor_id through models, then through queries, then through the cart, then through the admin, and every place you forget becomes a data leak where one seller sees another seller's orders. This guide takes the other path: build on Aimeos, a Laravel ecommerce package that's multi-tenant from the data model up, and spend your time on the marketplace instead of the plumbing.

Decide where tenancy lives

Before any code, pick the foundation honestly, because it determines how much of the next month you spend on isolation you'll never show a user.

Approach	Vendor isolation	Self-service onboarding	Scales to thousands of vendors
Build it yourself	you thread it through every query	you build it	you re-architect for it later
Single-tenant shop + add-on	bolted onto a single-tenant base	extension-dependent	medium
Aimeos	built into the data model, scoped per site	one env flag	designed for it, 1 to more than 1 billion items

Build it yourself looks cheapest on a whiteboard and turns out to be the most expensive. Tenancy is a cross-cutting concern: it touches every model, every join, every report and every API endpoint, and the cost isn't the scoping code you write — it's the one clause you forget. A single missing filter in a join is one vendor reading another's orders, and you find it in production, not review. It also never stays finished. Every feature you add afterwards has to re-earn its isolation, so you end up maintaining a multi-tenancy framework as an unpaid side project to the marketplace you actually wanted to build.

Single-tenant shop + add-on moves the problem rather than solving it. The base assumes one merchant, so the extension grafts vendor columns and filters onto a schema that was never designed for them. Isolation then lives in the add-on's discipline instead of the data layer — it holds where the extension remembered to apply it and leaks at the edges the base shop reaches directly: admin tools, exports, and third-party plugins that have never heard of vendors. On top of that you inherit the add-on's release cycle and price, and you're betting it keeps pace with the platform it's bolted to.

The rest of this guide assumes the third row, where isolation is a property of the data model rather than something layered on top. Each step is a flag or a small amount of config, not a sprint.

Stand up the backend

You need PHP 8.2+ and a database (MySQL, MariaDB, PostgreSQL or SQL Server). The distribution wires the storefront, the admin, the APIs and a seeded catalog in one command.

composer create-project aimeos/aimeos myshop

Answer the prompts for database, mail and the admin account, then look around:

cd myshop
php artisan serve

The storefront is at http://127.0.0.1:8000, the admin at http://127.0.0.1:8000/admin. At this point you have a working single shop. The next two steps turn it into a marketplace.

Enable multi-vendor mode

The multi-vendor machinery ships in the box. You switch it on with one line in .env:

SHOP_MULTISHOP=true

That gives every vendor a scoped storefront and a scoped backend at their own site — Aimeos's word for a tenant. You can see what the flag did in the routing: every route gains a {site} segment, so the storefront, the JSON:API, the admin panels and the seller's own backend all scope to the vendor in the URL.

'admin'    => ['prefix' => 'admin/{site}/jqadm',   'middleware' => ['web', 'auth', 'verified']],
'graphql'  => ['prefix' => 'admin/{site}/graphql', 'middleware' => ['web', 'auth', 'verified']],
'jsonapi'  => ['prefix' => '{site}/jsonapi',       'middleware' => ['web', 'api']],
'default'  => ['prefix' => '{site}/shop',          'middleware' => ['web']],
'supplier' => ['prefix' => '{site}/s',             'middleware' => ['web']],

The {site} placeholder isn't there for pretty URLs. It's the seam that keeps one vendor's administration from reaching into another's, all the way down to the API.

Let vendors onboard themselves

Creating each seller account by hand doesn't scale past a demo. Turn on self-registration:

SHOP_REGISTRATION=true

A newly registered seller gets administrator rights over their own site and nothing else — their catalog, their orders, their customers, their settings, none of anyone else's. If that's more power than you want to hand a fresh signup, drop the default permission level:

SHOP_PERMISSION=editor

And if neither "admin" nor "editor" maps to the access you have in mind, the permission sets are themselves configuration. Publish your own version of the admin resource config and decide exactly which panels and actions each role can touch. The platform operator keeps the root; vendors get precisely the slice you grant them.

Understand the isolation you just got

It's worth knowing why the two flags above are enough, so you trust the result instead of double-checking it forever. Aimeos organizes everything around the site. Every record the system stores — products, prices, orders, stock — carries a site id, and the data layer filters on it automatically. You never write the where siteid = ? clause; the manager that loads the data already added it. That single design decision is what turns "build a marketplace" from a tenancy project back into a normal shop project.

Sites form a tree rather than a flat list, so a parent can hold shared catalog, categories or configuration that child vendors inherit, while each vendor still owns and overrides their own. A platform operator runs the root; vendors live underneath it with their data sealed off from each other by default.

Give each vendor a catalog and a storefront

Each seller logs into a backend that looks like a complete shop because, scoped to their site, it is one. They manage their own products with the full Aimeos catalog model behind them — variants, bundles, vouchers, virtual and downloadable goods, configurable and custom products, and subscriptions with recurring payments. A marketplace rarely sells one shape of thing; the moment one vendor wants tiered B2B pricing while another sells monthly boxes and a third sells license keys, a thin product table becomes the bottleneck. Aimeos models all of it without schema surgery, so you don't have to say no to a seller's business model.

On the storefront side, each vendor has a public supplier page (the /s route from Step 2) — a branded presence inside the marketplace with their catalog, profile and listings. Buyers shop across vendors; the basket and checkout are shared; the data behind each line stays attributed to the vendor that owns it.

Handle the money

This is the step teams put off and regret. The marketplace-specific concerns — routing the lines of a mixed-vendor order to the right sellers, commissions, and seller payouts — live in a dedicated marketplace extension that builds on the multi-vendor core. The core gives you isolation and per-vendor administration for free; the extension adds the commercial layer of running a platform that takes a cut.

Settle the money at the gateway rather than reconciling it by hand afterward. Aimeos ships payment extensions built for marketplaces — Stripe among them — that split each transaction the moment it's captured, sending the platform its commission and forwarding the remainder to the seller who fulfilled the line. Payouts stop being a monthly spreadsheet exercise and become a property of checkout: the buyer pays once, and the money lands where it's owed, already divided. The same model covers the awkward cases a marketplace inherits — refunds that have to claw back the right share, and orders spanning several vendors that need several payees from a single basket.

Plan for scale before you need it

Marketplaces don't fail at launch. They fail when they succeed — when a few dozen vendors become a few thousand, each with thousands of SKUs, and the catalog that felt instant at 5,000 products crawls at five million. Scale is the requirement that's invisible on day one and existential by month eighteen.

You don't implement anything extra here; you inherit it. Aimeos runs the same architecture from a single seller up past a billion items, with render times down to around 20ms and response times near 100ms on a properly built catalog. The performance work a hand-rolled marketplace postpones until it's an emergency is the work this backend already did, so growth stays a business problem instead of becoming a database firefight.

Go headless where it pays

Vendors increasingly want their own tooling — a mobile app to manage listings, a custom analytics view, an ERP that pushes inventory. Aimeos is API-first underneath the bundled storefront: a JSON:API following jsonapi.org for the buyer side and a GraphQL API for administration, both already scoped per site. Drive the whole marketplace headless, give vendors programmatic access to their own data, or keep the included storefront and only go headless where it pays. None of those are a rebuild — they're the same backend addressed differently.

Verify it

The claim worth testing is the boring one: that the isolation is real and you didn't have to write it. With SHOP_MULTISHOP=true and SHOP_REGISTRATION=true set, create a couple of vendor accounts, sign in as each, and confirm the obvious thing from the inside — neither one can see the other's catalog or orders, and nobody wrote a scoping clause to make that true.

The live frontend demo and admin demo are up if you want a look first, the docs cover the multi-vendor setup end to end, and the marketplace extension is where the commission and payout layer lives.

Implementing a marketplace is mostly about not implementing the parts that should already exist. Start from a backend that's multi-tenant by design, and the thing you ship is the marketplace — not the plumbing underneath it.

PagibleAI: A CMS for your Laravel application

Aimeos — Mon, 22 Jun 2026 12:15:09 +0000

Add content management to a Laravel app you already run. Pagible is a Composer package that brings structured content, versioning, GraphQL and JSON:API, an AI editor, and an MCP server — without taking over your app.

Every Laravel project hits the same question eventually. The client wants to edit the content themselves, and you have to decide who owns the application.

None of the usual answers are clean.

Run WordPress in headless mode and you take on a second runtime, a second auth system, and a REST API you didn't design. Adopt a hosted platform like Contentful and you pay per record while your content lives on someone else's servers. Build a bespoke admin panel and you spend the next two months rebuilding a tree editor, a media library, and a draft/publish flow instead of shipping the product.

Approach	What you take on
Headless WordPress	A second runtime, a second auth system, a REST API you didn't design
Hosted platform (Contentful)	Per-record pricing, your content on someone else's servers
Bespoke admin panel	Months rebuilding a tree editor, media library, and publish flow
PagibleAI	One Composer package; your app stays yours

PagibleAI starts from a different premise: add content management to a Laravel app you already run. You composer require it, and your app stays your app. The CMS moves in as a set of packages, brings its own models, migrations, admin panel, and APIs, and stays out of the way the rest of the time.

Here's what stands out from a developer's seat.

The install is a normal Composer package

There's no service to host and nothing external to wire up. If you have a Laravel 11, 12, or 13 app on PHP 8.2+, you add the package and run the migrations. That's the whole install:

composer require aimeos/pagible
php artisan cms:install
php artisan migrate

Then grant yourself editing rights:

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

The admin panel is served from your own app at /cmsadmin. It's a Vue 3 and Vuetify single-page app talking to a GraphQL endpoint. No external dashboard, no webhook round-trips, no second deployment to keep in sync.

Underneath, it's a monorepo split into focused packages: core models, admin, AI, GraphQL, JSON:API, search, MCP, backup, import, and theming. They share the Aimeos\Cms\ namespace. You install one meta-package and get all of it, but each concern stays isolated, so the surface you have to reason about stays small.

What it's built on

There's not much exotic here. Each capability leans on a package the Laravel community already knows, so most of the stack is familiar before you read a line of Pagible's own code.

Package	Role
`laravel/framework`	Laravel 11 / 12 / 13
`nuwave/lighthouse`	GraphQL admin API
`laravel-json-api/laravel`	JSON:API content delivery
`laravel/scout`	Full-text search engine
`laravel/mcp`	MCP server
`laravel/reverb`	Real-time broadcasting (optional)
`laravel/cashier`	Payments and paywalls — Stripe, Paddle, Mollie (optional)
`aimeos/prisma`	Broad LLM provider integration
`aimeos/laravel-nestedset`	Optimized nested-set page tree
`intervention/image`	Image processing and previews
`league/commonmark`	Markdown rendering
`ezyang/htmlpurifier`, `enshrined/svg-sanitize`	Content sanitization

The admin panel is its own front end on top: Vue 3, Vuetify, and Vite, built into a bundle that ships with the package.

Content is structured, not a wall of HTML

This is what sets Pagible apart from the WordPress lineage. A page isn't one big rich-text field. It's a node in a tree that holds an ordered list of typed content elements.

Three models carry the weight:

Page — a node in a nested-set tree, with drag-and-drop reordering, UUIDs, and soft deletes.
Element — a content block with a type and a data payload. Pages reference their elements in order, and the same element can be shared across many pages.
File — media, with AI-generated descriptions and automatically sized previews.

cms_pages  (nested-set tree)
└─ Page ─┬─ ordered elements ── cms_elements   typed, reusable blocks
         ├─ attached files   ── cms_files      media + AI descriptions
         └─ every change     ── cms_versions   immutable snapshots

A content element is a small, typed structure:

[
    'id'    => 'ByC2ze',
    'type'  => 'text',
    'group' => 'main',
    'data'  => ['text' => '## A heading\n\nSome **markdown** body copy.'],
]

Each type maps to a Blade partial in the theme. The entire renderer for a text element in e.g. theme/views/text.blade.php is one line:

@markdown($data->text ?? '')

You get a generous set of ~30 content element types out of the box including:

Type	Renders
`text`	Markdown body copy
`hero`	Full-width banner with background media
`cards`	Grid of linked cards
`image-text`	Image alongside text
`pricing`	Pricing tables
`slideshow`	Image carousel
`code`	Syntax-highlighted snippets
`questions`	FAQ accordion

Adding your own type means defining its data shape and writing the partial that renders it. You keep full control of the markup, and you can override any view or drop in your own components.

One detail matters for security. The mapping from a type to its handler comes from a trusted schema keyed by the type name, never from the stored element data. A content author can't smuggle a different handler into a record's payload, which closes a whole class of injection problems before it starts.

The payoff is the one Contentful built a business on. Your front end consumes predictable, typed data instead of parsing arbitrary HTML. The same content can render as a web page, feed a mobile app, or drive a sitemap, with no one copy-pasting markup.

Two APIs, pointed in opposite directions

Pagible is API-first in a literal sense. The admin panel is just one client of the API, not a privileged path into the database.

Editing runs over GraphQL, built on Lighthouse. It's the read-write surface the admin uses, and the same one your own tooling, scripts, or integrations can talk to.

Delivery runs over a read-only JSON:API that follows the spec, tuned for the public side. The split is deliberate. The write API can afford to be expressive; the read API is built to serve content fast and cache hard. Rendered pages are cached per-page with a configurable TTL, a day by default, so the common case never touches the editing machinery.

Prefer to render server-side? The theme package ships Blade templates and small directives like @markdown and @localDate, and all of it is yours to override.

Versioning an editorial team can trust

Every change to a page, element, or file becomes an immutable snapshot in cms_versions. Editors see the latest draft. The public sees the most recently published version. Those are two different things, on purpose.

That model gives you the workflow features for free:

Save a draft without touching the live site.
Schedule a version to go live later. cms:publish promotes anything whose publish_at has passed, on a schedule.
Revert to any earlier snapshot when an edit goes wrong.
Keep a bounded history (ten versions per item by default) as an audit trail.

For teams, there's an unsaved-changes guard, concurrent-edit protection, and a Git-like three-way merge when two people touch the same content. A half-finished draft is never one stray click from production.

AI is wired in per task, not bolted on as a chatbot

The "AI" in PagibleAI isn't one assistant sitting in a corner. It's a set of content operations, each routed to whichever provider does that job best, configured by environment variable.

The defaults look like this:

Task	Provider
Write and refine copy, describe media	Gemini
Generate and edit images (inpaint, repaint)	Gemini
Translate	DeepL
Erase, isolate background, uncrop, upscale	Clipdrop
Transcribe audio	OpenAI Whisper

Each task reads its own CMS_AI_{TASK} / _MODEL / _API_KEY trio. You configure only the providers you use, and you can point any task at a different model or provider without touching code. There are batch commands too. cms:description, for example, walks through pages and media that lack descriptions and writes SEO meta text and alt text for them.

Translation is the standout. Content can be translated into more than 35 languages while keeping its structured shape intact, so a translated page is still a real page, not a flattened copy. The whole AI layer is there when you want it and out of the way when you don't — it's truly optional.

The MCP server is the genuinely new part

This is where Pagible reads the room. The same operations the admin panel performs are exposed as Model Context Protocol tools — 33 of them, covering pages, elements, files, image editing, translation, and search.

The result: an assistant like Claude can run the CMS the way an editor would. Not by scraping a UI or guessing at an undocumented API, but through typed tools with real authorization behind them.

"Draft a pricing page from these bullet points, generate a hero image, translate it into German, and schedule it for Monday" stops being a feature request. It becomes a sequence of tool calls an agent makes against your content, with the same permission checks and versioning a human edit goes through.

The CMS turns into something an agent can operate, not just a UI a human clicks through.

It works because the architecture was structured-first from the start. When content is typed and the operations are explicit, an agent has something solid to act on. That's the upside of not storing everything as a wall of HTML.

Scaling, and the boring parts that matter

The same install runs on a single SQLite file for a brochure site and on a database cluster for millions of pages. It's Octane-friendly and built for cloud-native deployment.

Search reflects that range. A custom Laravel Scout engine speaks the native dialect of whatever database you're on: FTS5 on SQLite, MATCH … AGAINST on MySQL, tsvector on PostgreSQL, CONTAINSTABLE on SQL Server. No separate search cluster for something the database already does.

Multi-tenancy is single-database by design. Every model is scoped by a tenant_id through a global Eloquent scope, resolved by the Laravel tenancy package you probably already use. Multi-domain routing is a config flag. Real-time collaboration is opt-in over Laravel Reverb, broadcasting compact, metadata-only events so two editors don't clobber each other.

The security posture is the kind you'd rather inherit than assemble: user content sanitized through HTMLPurifier, CSP headers enforced, hCaptcha on forms, URL validation on submitted links, and rate limiting across the API.

Migrating in? There's a WordPress importer that moves a site over with an Artisan command, plus per-tenant backup and restore with integrity checks.

Want to charge for content? A separate aimeos/pagible-cashier package wires Pagible into Laravel Cashier, so you can put pages behind a paywall or sell course access through Stripe, Paddle, or Mollie. Its installer prompts for a provider, writes the credentials, and adds the Billable trait to your user model. Like the rest, it's opt-in — install it only if you need it.

Who it's for, and the honest caveats

Pagible fits when you have a Laravel app and want the people who own the content to manage it without you handing over the codebase. The headless APIs, structured content, and MCP tooling make it a solid base for anything where content feeds more than one front end.

Two things to weigh. It's young and moving fast, and the AI features need third-party API keys, which means accounts and may need a budget if you want the full set.

It's MIT licensed, so you can use it in commercial work with no per-site fees and no lock-in.

None of the caveats change the central pitch, which is the thing I keep coming back to: it installs into your app instead of asking your app to live inside it. If you've ever lost a weekend to a headless WordPress proxy, that alone is worth the composer require.

Frequently asked questions

What is PagibleAI?

PagibleAI is an open-source content management system that installs directly into an existing Laravel application. It provides structured content, versioning, an admin panel, GraphQL, JSON:API, AI-assisted editing, search, and an MCP server without replacing your application.

Which Laravel and PHP versions does PagibleAI support?

PagibleAI supports Laravel 11, 12, and 13 on PHP 8.2 or newer. You install it as a Composer package, run its installer and migrations, and manage it through the Laravel application you already deploy.

Does PagibleAI take over my Laravel application?

No. Your Laravel application continues to own its authentication, business logic, data, infrastructure, and deployment. PagibleAI adds CMS packages, models, migrations, APIs, and an admin panel inside that application.

Is PagibleAI a headless CMS?

PagibleAI supports both headless and server-rendered websites. Public content is available through a read-only JSON:API, editing operations use GraphQL, and Laravel applications can render pages directly with Blade templates and CMS directives.

How does PagibleAI store content?

PagibleAI stores content as typed, structured elements rather than one large HTML document. Pages contain ordered elements such as text, heroes, cards, pricing tables, slideshows, code samples, and FAQ sections. Elements can also be reused across multiple pages.

Can I create custom content types?

Yes. A custom content type consists of a defined data structure and a Blade partial that renders it. The application controls the resulting HTML, and existing views can be overridden with project-specific templates or components.

How do drafts and publishing work?

Every change to a page, element, or file creates an immutable version. Editors work on the latest draft while visitors continue to see the last published version. Earlier versions can be restored, and future versions can be scheduled for publication.

Are the AI features required?

No. All AI features are optional. Writing, translation, transcription, image generation, background removal, and other operations can be configured separately, and you only need API credentials for the services you choose to use.

What does the PagibleAI MCP server do?

The MCP server exposes typed content-management tools for pages, elements, files, search, translation, and media operations. Compatible assistants can use those tools to draft, update, translate, and schedule content while going through the same authorization and versioning rules as human editors.

Which databases does PagibleAI support?

PagibleAI works with SQLite, MySQL, MariaDB, PostgreSQL, and SQL Server. Its search engine uses each database's native full-text capabilities, so a separate search service is not required for the standard setup.

Does PagibleAI support multiple tenants and domains?

Yes. CMS records are tenant-scoped in a shared database, and multi-domain routing can be enabled through configuration. This allows one Laravel installation to manage content for multiple tenants or websites.

Can PagibleAI protect private or paid content?

Yes. Pages and media can have access rules, and private files are delivered through protected routes. The optional Cashier integration adds paid access through Stripe, Paddle, or Mollie.

How is PagibleAI different from WordPress or Contentful?

Unlike headless WordPress, PagibleAI does not introduce a second application runtime or authentication system. Unlike a hosted CMS, it keeps content in infrastructure you control and has no per-record pricing. It is designed specifically for Laravel applications that need structured, reusable content.

Is PagibleAI free for commercial projects?

Yes. PagibleAI is released under the MIT license and has no per-site licensing fees. Optional AI providers, payment processors, hosting, and other third-party services may still have their own usage costs.

The code and docs are at pagible.com and on GitHub. If you try it, I'd like to hear which part of the workflow surprised you.

A working Laravel shop in five minutes with Aimeos

Aimeos — Thu, 18 Jun 2026 13:20:40 +0000

Adding a shop to a Laravel app usually turns into a quarter of work. You pick a cart library, bolt on a payment gateway, build an admin panel nobody asked to build, then discover your product model can't handle variants, bundles or tier prices without a rewrite. The ecommerce part eats the schedule; the Laravel part was never the problem.

Aimeos takes the opposite route. It's a Laravel package that brings the storefront, the admin backend, a JSON:API for the frontend, a GraphQL API for administration, and a product model built for variants, bundles, subscriptions and block pricing. You install it the way you install anything else in Laravel, and you have a running shop before your coffee is cold.

Here's the part people don't believe until they run it: the full setup is about five minutes. Two paths, depending on whether you're starting fresh or extending an app you already have.

Path one: a standalone shop

If you don't have an app yet, the distribution wires everything up for you. You need PHP 8.2+ and a database (MySQL, MariaDB, PostgreSQL or SQL Server).

composer create-project aimeos/aimeos myshop

During install it asks for your database credentials, your mail settings, and the email and password for the admin account. It runs the schema setup and seeds demo data as part of the same step, so when it finishes you have a populated catalog, not an empty shell.

Start it with the built-in server to look around:

cd myshop
php artisan serve

The storefront is at http://127.0.0.1:8000 and the admin backend at http://127.0.0.1:8000/admin. Log in with the account you just created. Catalog, baskets, checkout, orders and the dashboard are already there.

For hosting, point your vhost document root at myshop/public/ and set APP_URL in .env to your domain. That's the only deployment-specific change.

Path two: into an existing Laravel app

Already have an app and want a shop inside it? Require the package:

composer require aimeos/aimeos-laravel:~2025.10

Publish the config and assets, run the migration, and let Aimeos set up its tables:

php artisan vendor:publish --tag=config --tag=public
php artisan migrate
php artisan aimeos:setup

Append --option=setup/default/demo:1 to aimeos:setup if you want demo data to click through; leave it off in production.

Create a superuser for the backend:

php artisan aimeos:account --super you@example.com

It prompts for a password. The shop now lives under your app's routes, sharing the same Laravel session, auth and config. The frontend renders at / and the admin at /admin, alongside whatever your app already serves.

What you actually get

The install is short because the package isn't a starting point you finish writing — it's the finished thing, built to be customized rather than completed. Out of the box:

A storefront with catalog filters, search, basket, multi-step checkout and customer accounts.
A full admin backend with a dashboard for products, orders, customers, pricing and marketing.
A JSON:API following jsonapi.org for the frontend, so you can drop the bundled views and drive it from React, Vue or a native app.
A GraphQL API for administration if you'd rather manage data programmatically.
A product model that handles variants, bundles, vouchers, virtual and configurable products, plus subscriptions with recurring payments and block/tier pricing — without schema surgery.
Over 100 payment gateway integrations through Omnipay.
Multi-language routing, multi-vendor and multi-warehouse support, translated into 30+ languages.

It's designed to stay fast as the catalog grows, from a handful of products into the millions, which is the part that usually decides whether a shop survives its second year.

Customizing without forking

Every layer is replaceable through Laravel's own conventions. Configuration lives in config/shop.php. Templates are standard Blade views you override by copying them into resources/views/vendor/shop/. Business logic sits in decorators you register in config, so you change behavior by wrapping it, not by editing vendor code that the next update would overwrite. Turn on multi-language routing, multi-vendor mode or self-registration for sellers with a single .env flag each:

SHOP_MULTILOCALE=true
SHOP_MULTISHOP=true
SHOP_REGISTRATION=true

Try it

The honest test is to run it yourself rather than take the word count on faith. composer create-project aimeos/aimeos myshop, answer the prompts, php artisan serve, and open the browser. If you want to see the result first, the frontend demo and admin demo are live.

Docs are at aimeos.org/docs/latest/laravel, and if you're building a headless or PWA frontend, the Aimeos headless distribution ships API-only with JWT auth already configured.

Five minutes to a working shop. The rest of the quarter is yours to spend on the parts that make it yours.

DEV Community: Aimeos

Best AI CMS 2026: 8 compared on drafts, models and MCP

TL;DR

AI feature comparison

Contentful

Drupal

PagibleAI

Payload

Sanity

Storyblok

Strapi

WordPress

Which one should you use?

How I compared

Sources

Aimeos 2026.10: MCP tools for Laravel e-commerce

What's new

MCP tools for AI agents

WebMCP in the storefront

Choose an AI provider for each task

Imports and exports

Framework support

Security hardening

How Aimeos fits into your application

Get started

PagibleAI CMS 0.13: Review with AI, publish with confidence

Review a page before publishing

Edit without losing your place

Trigger integrations with signed webhooks

Purge CDN caches when content changes

Catch content errors before submitting updates

Import content from TYPO3 and WordPress

More in this release

Install or upgrade

The Best Laravel CMS: PagibleAI vs Statamic vs October CMS

Architecture at a glance

Adding the CMS to a Laravel application

Content storage and versions

Editorial and public APIs

AI and MCP permissions

Deployment

Statamic and October CMS

Statamic: Git-centered content with Pro licensing

October CMS: a site platform with its own conventions

When PagibleAI fits

PagibleAI: A Cloud-Native Laravel CMS, Not Just a Container

One application, one operating model

Durable state stays off the web node

Content in the database

Media on a filesystem disk

Cache and coordination

Commit first, then distribute

Built-in search, external engine optional

Headless and server-rendered delivery

Tenant context beyond the HTTP request

Realtime and long-running processes

Configuring a distributed deployment

What PagibleAI leaves to the deployment

How to customize Aimeos e-commerce projects without maintaining a fork

Choose the smallest extension point

Start with configuration

Compose pages from components

Keep the page shell, markup and theme separate

Add business rules with decorators

Put larger customizations in one package

Know when to replace the HTML frontend

What the structure costs

PagibleAI: The Best Headless CMS for Laravel

The CMS remains part of the application

What the package already settles

The Laravel alternatives

A deliberate boundary between editing and delivery

Content that survives the current frontend

The unglamorous work is already done

Where PagibleAI may not be the answer

A better use of development time

Frequently asked questions

What is PagibleAI CMS?

Is PagibleAI a headless CMS?

Does PagibleAI require a separate hosted service?