Laravel Knowledge Base Laravel Package

Product Decisions This Supports

• Gating premium or internal-only content: Private article assets now enforce article visibility per request, which makes the package viable for knowledge bases that mix public documentation, customer-only content, and internal SOPs in a single install. This supports tiered access, customer portals, and partner-facing documentation without a separate CMS.
• Build vs. buy for document/media delivery: The package now ships storage abstraction, signed URL issuance, per-request authorization, and a migration command. That shifts the calculus toward "buy/extend" for teams whose needs are article-centric, since the costly parts (ACL on assets, revocation, disk migration) are handled.
• Compliance and data-handling roadmap: Private disk + signed URLs + short-lived access is a prerequisite for security reviews, GDPR/DPA questionnaires, and enterprise procurement. It enables a "sensitive documentation" roadmap item (HR policies, legal docs, post-incident writeups) that previously had to be blocked or built bespoke.
• Cache-revocation policy is now a product decision, not a bug: cache_max_age versus signed_url_minutes is an explicit trade-off between CDN cost/performance and how fast access can be withdrawn. This is worth capturing as a documented policy (e.g., "revocation within 5 minutes for internal content").
• Migration/rollout planning: kb:move-assets --dry-run gives a safe rehearsal path for existing environments, which reduces the risk of scheduling an upgrade mid-sprint and lets you sequence the privacy change independently of feature work.
• Use cases newly unlocked: Customer-facing help centers with gated sections, internal wikis on shared infrastructure, vendor/partner documentation with expiring links, and incident-response runbooks restricted to staff.

When to Consider This Package

Consider it when:

• Your content model is fundamentally article/document-centric (categories, articles, attachments) rather than page-builder or commerce content.
• You need mixed visibility in one knowledge base — public docs plus internal, draft, archived, or hidden content — and cannot accept "unlisted but technically public" URLs.
• You require revocable access to files, auditability expectations from security/procurement, or signed-URL sharing (e.g., emailing a link to a client with an expiry).
• You are on Laravel and want the storage/ACL/migration concerns handled by the package rather than a custom media layer.
• You can accept route-served assets rather than direct object-storage URLs — i.e., you have capacity for asset traffic through PHP or have a CDN in front.
• Upgrade path from 2.0 is low-risk: existing assets resolve through the route immediately, and you can set attachments.route.enabled to false to defer the behavioural change. Good fit for a staged rollout.

Look elsewhere when:

• You need per-user, per-document entitlements (ACLs beyond article visibility), watermarking, DRM, or download audit logs — this release authorizes at article granularity only.
• Revocation must be instantaneous: browsers and CDNs may serve cached copies for up to cache_max_age seconds after an article becomes internal. If the requirement is "revoke now," either set cache_max_age to 0 and purge aggressively, or choose a system with token-per-request validation.
• You need large-file or video delivery at scale — proxying media through a Laravel route adds app-server load and bandwidth cost; direct signed object-storage URLs are a better architecture.
• You rely on search indexing of assets or SEO for documents; route-served private assets are not crawlable/indexable like static storage files.
• Your content needs localization workflows, structured content/headless delivery, or versioned publishing that a full CMS provides.
• You require vendor-managed support SLAs or a hosted admin UI — this is a community package (with community contribution credited here).

How to Pitch It (Stakeholders)

For executives: The knowledge base can now hold material that must not be public — customer-restricted documentation, internal policies, legal and HR content — in the same system as our public help center, with access checked on every request and expiring links for sharing. This removes a blocker for enterprise and regulated customers who ask how we protect internal documents, and it avoids buying a second CMS or building a bespoke permissions layer. Upgrade risk is low: current assets keep working, changes are opt-in via config, and there is a dry-run migration command, so we can ship in a scheduled window with a rollback switch.

For engineering: This is a config-and-migrate change, not a rewrite. Set attachments.disk to local or a private cloud disk, run php artisan kb:move-assets --dry-run then the real command, and decide on attachments.route settings. Two things need explicit decisions: (1) cache_max_age — it is the effective revocation window for internalized articles, so treat it as a security parameter, not a performance knob, and consider a CDN purge step; (2) the route now serves asset bytes, so keep middleware tight (auth, throttling) and front it with a CDN for public content. Note the old /storage/... URLs remain live for files still on the public disk until assets are moved — don't leave that step for "later." There is also no per-user ACL beyond article visibility, so flag any requirement that goes further before committing.