Canvas for Laravel: a self-hosted publishing platform you drop into an existing app

The problem Canvas solves for Laravel teams

Most blogging tools assume they own the site. You install WordPress or Ghost, and now you have a second user table, a second login, a second deployment, and a second set of backups. Canvas takes the opposite position. It is a Composer package that drops into a Laravel application you already run, and it uses the authentication you already have. The README states this directly: "Drop it into an existing application, use your own authentication, and start writing."

The audience is narrow and specific. You need to be on Laravel 12 or newer and PHP 8.3 or newer, and you need working authentication for the guard Canvas uses, which defaults to web. If you are building a product where a blog is a side feature rather than the main event, that constraint is the whole point. Your users, your sessions, and your roles stay in one place. The cost is that Canvas cannot be adopted by anyone outside the Laravel ecosystem, and it will not run as a standalone service.

What the package actually adds to your application

Canvas ships an admin surface at /canvas and an optional public reader frontend at /canvas-ui. The editor is described in the README as distraction-free, with tags, topics, and media uploads. Around that sit monthly trends and reader insights, three roles (Contributor, Editor, Admin), and integrations for Unsplash, AI writing, outbound webhooks, and a weekly digest.

The repository layout shows where the work happens. There is a src/ directory for the PHP package, config/ for publishable configuration, database/ for migrations, routes/ for the registered endpoints, and resources/ for the frontend. The package.json file is telling: it is marked private and lists React 19, TipTap 3.x with a long list of extensions (image, link, table, task list, code block, YouTube, audio, typography, text alignment, character count), Tailwind, and Motion. So the editor is a React application built with Vite, not a Blade form. That matters if you intend to customize it: you are working in TypeScript and React, not in server-rendered templates.

The test setup also signals the intended quality bar. The repository includes phpunit.xml.dist, phpstan.neon.dist, vitest.config.ts, and playwright.config.ts, with npm scripts for lint, typecheck, unit tests, coverage, and end-to-end runs. A package that ships Playwright configuration expects its admin UI to be exercised in a browser, which is more than many Laravel packages bother with.

Installing Canvas and publishing your first post

Installation is two commands. The first pulls the package from Packagist, the second runs Canvas's own installer, which the README presents as the setup step after requiring the package.

composer require austintoddj/canvas
php artisan canvas:install

After that, grant admin access to a user that already exists in your application. This is the clearest expression of the design: Canvas does not create accounts, it promotes yours.

php artisan canvas:make-admin [email protected]

With that done, the README says to visit /canvas in your browser. That is the admin area where writing happens. If you also want the optional public blog, run the UI command and visit /canvas-ui.

php artisan canvas:ui

The README is explicit that Canvas UI "is not required for Canvas to work." If you already have a frontend, or you want to render posts through your own controllers, you can skip this command entirely. The docs/content.md file is where the README points for building a custom frontend.

Upgrades, migrations, and the cost of staying current

Canvas follows Semantic Versioning, and the README splits the risk accordingly: major versions may contain breaking changes and come with a step-by-step guide in .github/UPGRADE.md, while minor and patch versions should never break anything. The routine update is three commands.

composer update austintoddj/canvas
php artisan canvas:migrate
php artisan canvas:publish

That is a real maintenance obligation, not a one-time install. Every update runs migrations against your database and republishes assets. The README offers to automate the second half by adding a Composer script to your application's composer.json.

{
    "scripts": {
        "post-update-cmd": ["@php artisan canvas:publish --ansi"]
    }
}

Note what that hook does not cover: canvas:migrate still has to run. The release history shows why the major-version path deserves attention. v6.0.56 landed on 2026-06-12, v7.0.0 on 2026-07-26, and v7.1.0 on 2026-09-14. Two majors in roughly three months is a fast cadence, and anyone pinned to v6 should read the upgrade guide before moving. The last push to the repository was on 2026-09-14, the same day v7.1.0 was tagged.

Where Canvas is the wrong tool

The requirements are hard gates, not suggestions. PHP 8.3 and Laravel 12 are the floor. A team on Laravel 10 or 11 cannot install this without upgrading the framework first, and that upgrade may be far more expensive than the blog feature is worth. Canvas is also not a standalone product. There is no separate login, no independent deployment, and no path to running it outside Laravel. If you need a CMS that a non-technical editor can administer without touching a Laravel codebase, this is the wrong shape.

The authentication requirement is the subtler trap. Canvas uses the web guard by default, and the README lists "working authentication for the guard Canvas uses" as a requirement. Applications that authenticate through a different guard, an API token flow, or a single-sign-on layer that does not populate the web guard will need configuration work before /canvas is usable. The README points to docs/configuration.md and docs/authorization.md, but the top-level readme does not spell out what that configuration looks like. Treat guard compatibility as the first thing to verify, not the last.

There is also a frontend split worth naming. The admin editor is React and TipTap, the package is PHP, and the optional public UI is a third surface. Customizing the writing experience means working in the JavaScript toolchain with Vite, ESLint, Prettier, Vitest, and Playwright. If your team is PHP-only, plan for that.

Canvas compared with a standalone blog engine

The obvious alternative is a dedicated publishing platform such as WordPress or Ghost, deployed as its own application. The difference is architectural rather than feature-by-feature. A standalone engine owns the database, the user table, the login, the theme layer, and the deployment. You get a mature editorial interface and a plugin ecosystem, and you pay for it with a second system to host, patch, and back up, plus a second identity for every author.

Canvas inverts that trade. It gives up independence and the plugin ecosystem in exchange for sharing your application's users, sessions, and deployment pipeline. There is no second login to provision and no second database to keep in sync. The cost is that Canvas lives and dies with your Laravel version, and its release cadence becomes your maintenance cadence. A team that already runs Laravel and wants a blog inside the product will find that trade favorable. A team whose blog is the product, or whose editors are not developers, will not.

Editorial conclusion

Adopt Canvas if you already run Laravel 12 on PHP 8.3 or newer and want publishing inside that application, with your own users and guard. Do not adopt it if you want a standalone CMS with its own login, or if you are on an older Laravel release. Before committing, verify that the web guard Canvas defaults to matches your authentication setup, and confirm the upgrade path by reading .github/UPGRADE.md alongside the v7.0.0 and v7.1.0 release notes.

Frequently asked questions

Official sources

1. austintoddj/canvas on GitHub
2. License: MIT
3. Project website
4. README
5. Releases