Voyager Blog Laravel Package

Product Decisions This Supports

• Content/blog capability for Voyager-backed admin panels. It answers the question "do we get a blog for free, or is this a build item?" for products already running Voyager as their Laravel admin.
• Build vs. buy (more accurately: build vs. integrate). A blog post model, migration, and Voyager BREAD configuration represent roughly 2–5 engineer-days of work. This package is the "integrate" option, with the caveat that it is archived.
• Scope for marketing/editorial features. It supports a minimal viable content model — title, slug, body, publish state — which is useful for deciding whether early content needs are simple CRUD or require workflow, scheduling, and media pipelines.
• Roadmap sequencing. If blog content is not a near-term revenue lever, adopting a thin module (or forking it) lets the team defer a CMS decision instead of committing to one now.
• Use cases it fits: internal company blog, changelog/announcements, a small marketing blog on an existing Voyager app, or an MVP where content volume is low and authoring is done by technical staff.
• It does not support decisions around SEO tooling, localization, editorial workflows, or multi-tenant content — none of that is in scope here.

When to Consider This Package

Consider it when all of the following hold:

• You already run Voyager in a Laravel app, and content authoring would live in that same admin (no separate CMS to operate).
• You need basic blog CRUD quickly and the content is low-stakes — internal, non-transactional, not regulated.
• You are willing to pin Laravel/PHP versions, vendor the code into your repo, and own it as a fork. Archived means no upstream fixes, no compatibility updates, and no security response.
• The 39-star adoption signal is acceptable because you can read the entire source in an afternoon and audit it.

Look elsewhere — or build — when:

• You are on a current Laravel release (10/11/12) and expecting this to track framework changes. It won't.
• You need features the module does not provide: revisions, editorial roles, scheduling, tags/taxonomy, comments, search, i18n, or SEO metadata.
• Content is customer-facing and brand-critical, or subject to compliance/accessibility obligations you'd rather not hand-roll.
• You need vendor support, SLAs, or a dependency that passes procurement review.
• Voyager itself is not already in your stack. Pulling in an unmaintained admin panel and an unmaintained module to get a blog is a net-negative trade.

Realistic alternatives: build the model + BREAD directly in Voyager (a day's work, no extra dependency), use a maintained admin stack (Filament, Nova) with a custom post resource, or adopt a headless CMS (Sanity, Contentful, Strapi) if content is a real product surface.

How to Pitch It (Stakeholders)

To executives: There's a free, small open-source plugin that adds a blog to the admin panel we already use. It could save a few days of engineering time on an internal or low-traffic blog. The catch is that the project is archived — nobody maintains it, patches it, or answers questions — so we'd be adopting the code as our own. That's fine for a low-stakes internal blog and a bad idea for anything customer-facing or long-lived. My recommendation is to treat it as a reference implementation or a time-boxed head start, budgeted at roughly one engineer-week to vendor, upgrade, and secure, rather than as a platform commitment.

To engineering: It's a thin Voyager module — model, migration, and BREAD config for posts. Small surface area, easy to read end-to-end. The practical work is not integration; it's ownership: pin dependencies, fork into our repo, patch Laravel compatibility, and run a security pass on the migrations and any file uploads. If we don't want that overhead, building the equivalent directly on Voyager BREAD is comparable effort with no third-party risk. Decide based on whether we're keeping Voyager as our admin layer at all.