Simple CMS: a Laravel starter that hands you a working admin panel

A teaching template, not a product with a support team

The description line calls this project a 'Laravel CMS for starters', and the README repeats the intent: it is built as a learning resource and starter template for people new to Laravel or Filament. The stack is stated plainly as Laravel 13, Filament 5, DaisyUI 5 and Lucide Icons, and the README says it works well with AI coding assistants such as Claude Code. That framing matters when you judge the codebase, because a teaching template is judged by whether its code reads clearly and by how much scaffolding it saves, not by how many features it carries.

The feature list is still concrete. There is an admin panel powered by Filament 5, content management for articles, categories and pages, a media library built on Spatie Media Library, an analytics dashboard with charts and statistics, admin and editor roles with different permissions, and a frontend described as a clean editorial style using DaisyUI 5, Tailwind CSS 4 and Lucide Icons. The top level of the project holds the usual Laravel skeleton plus a few telling additions: CLAUDE.md, vite.config.js, phpunit.xml and a .npmrc.

The install path is nine steps and it lands on SQLite

The requirements are PHP 8.3+, Composer, Node.js 18+ and npm or yarn. Installation starts with a clone, and the whole sequence fits on one screen. Step one gets the code down:

git clone https://github.com/ozdemirburak/simple-cms.git
cd simple-cms

Composer and npm follow, and the project ships an .npmrc with ignore-scripts=true, which the README presents as a way to reduce npm supply chain attack surface. That setting means lifecycle scripts of dependencies do not run during install, which is worth knowing if a package you add later depends on a postinstall step.

composer install

npm install

Environment setup copies the example file and generates a key:

cp .env.example .env
php artisan key:generate

The default configuration uses SQLite and the database file is created automatically, so there is no separate database server to configure before migrating. The .env.example ships with APP_ENV=production and APP_DEBUG=false, and SESSION_SECURE_COOKIE=true with a comment that says to set it false only for local HTTP development, which matters when you run the site on http://localhost.

Seeding writes two logins whose password is the word password

Migrations create the schema, and the seeder populates it. Running the default seed creates two accounts, and the README lists them in plain text: [email protected] and [email protected], both with the password 'password'. These are the accounts you will use to see the two permission levels behave differently.

php artisan migrate

php artisan db:seed

A second option adds sample content on top of the same base seed:

php artisan db:seed --class=ContentSeeder

That adds sample categories, articles and four pages: Privacy Policy, Terms of Service, About and Contact. Storage has to be linked before image uploads work, because the media library writes into the public storage area:

php artisan storage:link

Then the frontend assets are built and a server is started. npm run dev is the watch mode, npm run build produces production assets, and the README also mentions Laravel Valet or Herd for a custom domain like cms.test.

npm run build

php artisan serve

The admin panel then sits at /admin, which the README lists as http://localhost:8000/admin.

Ownership is the sharpest idea in the codebase

Simple CMS does not treat every admin user as equal, and the mechanism is worth reading before you extend it. Content ownership is tracked through a user_id column on articles, pages and media. Two pieces keep authorization and list views aligned: an OwnerablePolicy and a shared BelongsToOwner trait that adds a visibleTo() query scope to the Article, Page, Media and MediaItem models. Both follow the same own-or-orphan rule.

An orphan is a record whose original owner was deleted. The rule is that an editor can see and edit content they own plus orphaned content, so records are not permanently locked from anyone but admins. Deleting a user preserves their content by setting ownership to null through nullOnDelete, and other editors can then take it over. Force delete stays admin-only.

Roles are exactly two. An admin has full access, including user management, and can see and manage all content regardless of ownership. An editor manages articles, categories and pages, has no user management, and sees their own content plus orphans. The editor role is therefore a real constraint rather than a label, and the same scoping is applied to the dashboard widgets, with the Total Users statistic reserved for admins.

Images go into storage/app/public through Spatie Media Library

The media library is a Filament panel section powered by Spatie Media Library and its Filament plugin. The feature set is more than a bare upload field: multiple image upload at once with drag and drop, reordering images before upload, an image editor for crop and rotate, a listing of all uploaded images across the CMS, previews showing size, type and URL, copying image URLs for use in content, filtering by collection or model type, and deletion of unused images.

Storage location is documented plainly: images are stored in storage/app/public/. That is why the storage:link step is listed as required for image uploads. The Filament disk configuration in the app determines which disk is active, and the .env.example sets FILESYSTEM_DISK=local with CACHE_STORE=database and SESSION_DRIVER=database, so a SQLite file carries sessions, cache and queued jobs in a single file by default. The README does not document how to move uploads to S3, though the environment example carries the usual AWS bucket and region variables.

Analytics counters are cached for 60 seconds per user

The dashboard has four widgets: a stats overview with total views, articles, categories, pages and users; a line chart of daily article views over 30 days; a most viewed articles table; and a recent articles list. Under Analytics there is also an Article Views resource that shows detailed view logs with filtering.

The caching detail is the one to note. Stats are cached per user for 60 seconds and invalidated automatically on relevant content changes or role updates. Because the cache key is per user, two admins looking at the same dashboard at the same moment can briefly see different numbers, and a view counter that updates every request will not show up instantly on the chart. The project also tracks a view count on each article itself, shown as a column in the admin article list, and articles carry a published status and date alongside an optional excerpt, a featured image and an optional category.

What the project leaves out: releases, a license and audit trails

Three gaps are visible without running anything. First, the project has no GitHub releases, so there is no version history to upgrade to and no changelog to read. The last push was on 2026-08-02, and nothing in the listing suggests a tagged or published artefact you can pull instead of cloning. Second, no license identifier is stated in the project listing and the README does not choose one, so the legal status of anything you build on it is unstated and you should settle that yourself before publishing. Third, the read side is thin: the public routes are a home page, an articles listing with category filters, an article page, a category page and a static page route, with no search, comments, tags or RSS described anywhere.

The seeded credentials are the other sharp edge. A default install has two accounts with the password 'password', so a deployment that skips the cleanup step exposes an admin panel to anyone who has read the README. This is a starter, so that is normal, but it is the first thing to change.

The alternative is wiring Filament into a Laravel app you already own

The obvious alternative is not another CMS package but a different order of operations: keep an existing Laravel application and add a Filament 5 panel to it, defining your own models, policies and admin resources. The difference in approach is where the content model comes from. Simple CMS arrives with articles, categories, pages, media, the owner-or-orphan policy, the visibleTo() scope, the cached dashboard widgets and a public frontend with its own routes already written and a seeder to fill the tables. Building a panel by hand in an existing app means all of that is yours to write, and you inherit the rest of your app's conventions instead of the template's.

The trade-off runs the other way as well. Because Simple CMS is a template rather than a package, there is no Composer dependency to require and no upgrade path to follow; a new release of Filament or Laravel would be adopted by editing the project in place. For a team that already has a Laravel codebase and a working user model, the template adds little and takes away a coherent set of opinions. For someone learning Filament, it removes the boring half of the work and leaves the interesting half, which is the stated purpose of the project.

Editorial conclusion

Adopt Simple CMS as a teaching scaffold or a throwaway prototype if your goal is to see Filament 5 wiring, ownership rules and a public reading frontend in one repository. Do not ship it to real users as is: the seeded accounts use the password 'password', no license identifier is stated, and the last push was on 2026-08-02. Before anything else, replace the seeded credentials, decide the license yourself, and check that the Filament 5 and Laravel 13 versions match the PHP 8.3+ floor the project requires.

Frequently asked questions

Official sources

1. Issues
2. ozdemirburak/simple-cms on GitHub
3. README