Approval Laravel Package

Product Decisions This Supports

• Build vs. buy for community: Flarum is a candidate when the roadmap includes a customer community, support forum, or discussion layer. Buying a mature PHP forum and integrating it against our Laravel identity layer is almost always cheaper than building threads, moderation, search, permissions, and notifications from scratch — realistically 2–4 engineer-quarters of work we would otherwise defer.
• Architecture: sidecar vs. in-app: This is not a Composer package we composer require into the Laravel app. It is a standalone PHP application deployed alongside it, integrated via shared session/SSO, webhooks, or an API. That decision (separate service + separate upgrade cadence + separate ops surface) is the real product/architecture commitment, not the library choice.
• Platform version policy: The fact that the project is shipping point releases on a 2.x line is the useful signal here. It means 2.0.0's breaking changes are behind us, the 2.x API surface is settling, and we can plan an integration against 2.x rather than betting on a pre-1.0 or freshly-major-versioned target.
• Roadmap sequencing: Community work is usually a "later" item. A stable, self-hostable option lets us keep it off the critical path — a spike plus an integration ticket — instead of staffing a build.
• Extension ecosystem as a scope lever: Flarum's extension model is where most feature requests (reactions, gamification, SSO providers, spam mitigation) get satisfied without forking core. This changes estimates: features become "configure/install" line items rather than engineering.
• Migration and support risk: If we already run a 1.x instance, the 2.x line is the upgrade target and should be scheduled deliberately, not opportunistically. Patch releases like 2.0.1 are the low-risk window for that work.

When to Consider This Package

Consider it when:

• The product need is a discussion/community surface — threads, categories, tags, moderation queues, mentions, notifications — not a chat or a ticketing system.
• We are a PHP shop with Laravel in production, so a PHP forum is operationally familiar: same runtime, same deploy patterns, same on-call skills.
• We need SSO against our existing user table. Integration effort is bounded and well-understood; identity stays with us.
• SEO-indexable content matters (public discussions driving acquisition). Server-rendered forums still outperform SPA chat tools here.
• We want a self-hosted, data-owning option — regulated data, no per-seat SaaS pricing, no vendor lock on community content.
• We can accept a separate deployable service: own database (or schema), own upgrades, own backups, own monitoring.

Look elsewhere when:

• We need a deeply Laravel-native model — Eloquent models, policies, Nova/Filament admin, the forum's data living in our app's schema. Here a Laravel-native forum package or a headless API + our own front end fits better.
• We need real-time chat/presence as the primary interaction; that is a different product category.
• The requirement is enterprise SLA and vendor accountability — this is community-maintained OSS; support is our problem.
• The team has no appetite for running another PHP service (container, queue worker, cron, object storage, search), or platform policy mandates a single deployable.
• We need a guaranteed long-term-support contract tied to our release calendar.
• Volume is high enough that search and read scaling become their own project; a managed community SaaS may be the cheaper answer.

On this release specifically: v2.0.1 is a patch on a fresh major. Treat it as stability confirmation on 2.x, not as a feature decision. Pin the exact version, read the changelog before upgrading, and budget the 1.x → 2.x jump (if applicable) as its own ticket with extension-compatibility checks — extensions are where major upgrades actually break.

How to Pitch It (Stakeholders)

For executives: We have a recurring ask for a customer community — a place for users to ask, answer, and search. Building that ourselves is a multi-quarter engineering commitment with a permanent maintenance tail. Flarum is a mature, self-hosted PHP forum that we can stand up and connect to our existing login, so we own the content and the data and pay no per-seat fees. It is currently shipping patch releases on its 2.x line, which tells us the platform has stabilized after its major release — the right moment to integrate rather than a risky bet on something immature. The trade-off is honest: it is a second service to operate, and support comes from the community, not a vendor. Recommendation: approve a short spike to validate SSO and extension coverage, and treat the production rollout as a scoped project rather than an open-ended build.

For engineering: This is a standalone PHP app, not a package we pull into the Laravel codebase — we integrate at the edges (auth/SSO, webhooks, optionally a shared data sync) and keep our domain model clean. Upside: mature forum semantics for free, plus an extension ecosystem that absorbs most "nice-to-have" forum features without forking core. Costs: another container, database, queue worker, cron, and object-storage bucket in our platform; an independent upgrade cadence; and extension compatibility as the primary upgrade risk. Concretely: pin to an exact 2.x patch, evaluate extensions against 2.x before committing, run the SSO integration as a timeboxed spike, and if we are on 1.x, schedule the major upgrade as its own workstream with extension audits up front.