Canvas Laravel Package

Product Decisions This Supports

• Build vs. buy for owned-media publishing. Canvas replaces the "should we stand up WordPress, pay for a headless CMS (Contentful/Sanity), or build an admin CRUD" decision with a fourth option: install a Composer package into the Laravel app we already run. The decision reduces to a sprint or two of integration work versus a recurring SaaS line item or a multi-quarter internal build.
• Where content marketing lives. Marketing/blog/changelog/docs-adjacent content can ship from the same codebase and deploy pipeline as the product, under our domain, with our auth and our database — no second hosting surface, no cross-domain SEO fragmentation, no separate content team toolchain to procure.
• URL and slug strategy for published content. As of v7.2.3, a new post's slug derives from its title instead of defaulting to post-{uuid}. That converts a previously opaque, non-indexable URL pattern into readable, keyword-bearing ones — which matters for SEO, social previews, and sharing. Two caveats worth recording as decisions: (a) the fix applies to newly created posts, so if we adopt now we should decide our stance on any pre-existing post-{uuid} rows (leave, backfill, or redirect), and (b) slug derivation is now a behavior we depend on, so a future change to slug rules becomes a potential breaking change to live URLs we'd need to plan redirects around.
• Roadmap sequencing for editorial features. Because roles are fixed at Contributor / Editor / Admin and the publish wire is a documented HTTP contract (published_at in ISO-8601), we can scope a v1 with the roles as shipped and defer custom approval chains, per-team permissions, or legal review steps to a later phase — with a clear signal of what we'd be customizing.
• Automation and distribution strategy. Webhooks plus a weekly digest integration mean publishing can trigger downstream work (social syndication, newsletter, Slack announcements, search indexing) instead of being a manual copy-paste step. That's a roadmap input: if content distribution is a growth bet, this makes the pipeline buildable now.
• Internationalization as a non-decision. 17 locales ship in the box with a maintained en source-of-truth catalog. If we expand into non-English markets, UI localization isn't a project — content localization still is (and remains our problem).
• Buy-in vs. fork signal. The committed prebuilt SPA (resources/dist/) means hosts get a working admin UI with no Node build step in our CI. That's a real ops decision: adopt as-is and treat UI as vendor-owned, or budget for a fork if our design system or admin shell must match ours. Note that every release — including patch releases like this one — ends with php artisan canvas:publish, which republishes those assets. A fork therefore has an ongoing re-apply cost, not a one-time one.

When to Consider This Package

Adopt when all of the following hold:

• The host application is Laravel 12 or 13 on PHP ≥ 8.3. This is a hard gate — the package requires illuminate/* contracts only and is not a fit for Lumen, Symfony, or an older Laravel LTS we can't upgrade.
• We want content inside our existing app and database, not as a separate service. Data ownership, backups, and GDPR posture stay on infrastructure we already govern.
• Our editorial model is small-team: a handful of authors, editor review, publish/schedule. Three roles are sufficient; we're not solving for newsroom-scale workflows or complex multi-brand permissions.
• We can live with vendor-shaped admin UI. The React SPA is comprehensive but not ours; restyling means rebuilding resources/js/ and committing our own dist.
• We can operationalize a routine upgrade ritual: composer update → php artisan canvas:migrate → php artisan canvas:publish. That's a self-supported dependency — MIT, no SLA, no paid tier — and someone on the team must own running those steps and reading .github/UPGRADE.md before each bump.

Look elsewhere when:

• We need a headless/API-first CMS serving a decoupled Next.js or mobile frontend with its own content modeling. Canvas is a Laravel-rendered publishing surface with a package SPA, not a general content API for arbitrary consumers.
• Content needs arbitrary structured models (product catalogs, knowledge bases with typed fields). Canvas is post-centric.
• We require enterprise guarantees — support contracts, security SLAs, compliance attestations, or a vendor who will hold our hand through upgrades.
• The team has no Laravel depth. The package expects host familiarity with service providers, published config, migrations, and middleware.
• Diligence status: partially de-risked, not closed. v7.2.3 is a small, focused patch (one bug fix, no breaking changes, no deprecations, no new config surface), and it is exactly the kind of unglamorous maintenance work we want to see — it moves the "is this actively maintained?" question in the right direction. It does not by itself resolve the earlier flags: the registry still shows 0 dependents and a middling overall score (~51.8, opportunity ~1.55), and the future-dated release metadata remains a data-quality issue to verify against the repo's actual history. Action stands: confirm commit cadence over a longer window, open-issue responsiveness, and bus factor before committing roadmap to it. One patch release is a data point, not an answer.

How to Pitch It (Stakeholders)

For executives — the one-liner: We can have a production-grade, self-hosted publishing platform in our existing Laravel app for the cost of an integration sprint, instead of a CMS license, a headless-CMS subscription, or a homegrown admin build. MIT licensed, data stays in our database, no vendor lock-in — if we ever walk away, the content is just rows in our own schema.

The trade we're making: we take on maintenance ownership (upgrades, asset republishing) in exchange for zero recurring cost, full data control, and no second platform to secure, back up, and staff. That's the right trade for owned-media content, which is not a differentiated system for us.

For engineering — why it's low-friction: it's a package, not an app. Dependencies are illuminate/* contracts, not laravel/framework, so it composes into the host rather than imposing a scaffold. It has its own Pest/Testbench suite with a 98% coverage floor, static analysis at Larastan level 6, and documented PR gates — quality signals we can audit. Admin assets ship prebuilt, so no Node toolchain enters our deploy path. There's an optional HasCanvasAccess concern rather than a forced user-model change.

For engineering — the honest caveats: single-package maintenance risk and no support contract; every upgrade requires reading UPGRADE.md, running canvas:migrate, and republishing assets. The just-shipped v7.2.3 illustrates the shape of it well: a genuinely useful fix (new post slugs now follow the title rather than post-{uuid}) that we would want, delivered in a release that still asks us to run migrate + publish. That's cheap, but it is ours to run, on our schedule, every time. Supported matrix is Laravel 12/13, so it constrains future framework choices; the admin UI is vendor-owned unless we fork; and slug behavior is now something we depend on, so we should own redirects if the rule ever changes.

Ask: approve a timeboxed spike — install in a staging branch, wire auth and roles, publish one post end-to-end, confirm slug generation and the canvas:migrate/canvas:publish steps fit our deploy pipeline, validate the webhook path into our existing automation, and report back on integration cost and upgrade ergonomics. Decision to adopt or reject comes from that spike, not from this memo.