Framework Laravel Package

Technical Evaluation

Architecture fit The first thing a TPM must correct in the framing: flarum/framework is not a Laravel package, and it cannot be composer required into a Laravel application. It is a standalone, opinionated forum application whose "framework" package is the core runtime that Flarum's own extensions are built against. It consumes selected Illuminate and Symfony components (container, database layer, validation, HTTP kernel concepts), so Laravel engineers will recognize ~60% of the idioms, but it ships its own bootstrap, its own CLI (php flarum, not Artisan), its own service-provider/extender model, and its own JSON:API layer. Treating this as a library to embed is the single most expensive misconception available here.

The realistic architectural position is an adjacent deployable, not a dependency: a second PHP application on the same infrastructure, joined to the Laravel product at three seams only — identity (SSO), data (JSON:API + webhooks/events), and presentation (link-out or reverse-proxy under a subdomain/path).

Integration feasibility

• Identity: viable and cheap. Flarum supports OAuth2/OIDC and SAML through extensions, so a Laravel Passport/Socialite-backed IdP can be the system of record. Sharing Laravel's session cookie directly is technically possible in a single-domain deployment but is a trap — Flarum's session handling, CSRF and cookie config diverge from Laravel's, and any Laravel session-format change silently logs out the forum.
• Data: the JSON:API surface is the correct contract. Write integration against it, not against Flarum's MySQL schema — the schema is an internal detail that 2.0 is actively rewriting.
• Events: outbound integration relies on third-party extensions (webhooks, audit logs) rather than a first-party event bus. Each one is a maintenance dependency you inherit.
• Embedding UI: Flarum is a Mithril.js SPA. It assumes it owns the page. There is no supported "render this forum panel inside my Blade view" path.

Technical risk

1. Migration-in-flight. The 1.x → 2.0 transition breaks extension APIs. Anything you build against a beta extension API has a short shelf life. Underwrite only core APIs, and pin the minor version.
2. Maintainer concentration. A small core team plus a long tail of volunteer extension authors. Bus factor on core is acceptable; bus factor on any given extension is effectively one person, often unpaid.
3. Database constraint. MySQL/MariaDB only in practice. If your Laravel estate is Postgres, this is a second database technology for your platform team to own.
4. No native multi-tenancy. One forum per install. If your product is per-tenant, you are signing up for N instances or a tenancy layer you build yourself.
5. Release metadata quality. The stated last release of 2026-10-14 is future-dated relative to any defensible baseline — a data-integrity smell. Verify the actual release feed and tag dates from Packagist/GitHub before any planning number leaves your desk.
6. Opportunity score of 32.4 corroborates the thesis above: the ecosystem is mature and self-sufficient, with little room for a TPM to add differentiated value by extending it. Value accrues from deploying and integrating it, not from building on top of it.

Key questions

• Is the forum a product surface (users stay in-app, need SSO and shared notifications) or a community annex (link-out, separate login tolerated)? This single answer changes the estimate 3x.
• Who is the IdP of record — Laravel or Flarum? Flarum must never own credentials.
• Is there a hard requirement for content search across product + forum? If yes, budget an external index; Flarum's search is forum-scoped.
• Which extensions are load-bearing for the product (SSO, moderation, gamification, spam), and what is each one's release cadence and author activity?
• Can we commit to one minor version pin per quarter with a named owner for upgrades?
• Is MySQL already in the estate? If not, who owns the second datastore?
• Do we have a documented position on user-generated content liability (moderation, GDPR export/erasure across two datastores)? A second user store is a second subject-access-request surface.
• What is the exit cost — can we export topics/posts in a usable format if we abandon it in 18 months?

Integration Approach

Stack fit Strong at the infrastructure layer, weak at the application layer. Flarum runs on the same PHP 8.2/8.3 + PHP-FPM + Nginx + MySQL + Redis substrate a Laravel team already operates, so marginal infra cost is near zero. Composer, PHPUnit, Pint-adjacent tooling and CI patterns carry over. What does not carry over: Artisan, Eloquent models, Blade, Laravel's queue/scheduler semantics, and Laravel's authorization layer.

Migration path Do not migrate into Flarum's schema directly. Sequence:

Compatibility

• Pin the core and every extension to exact versions; treat composer update on the forum as a change-managed event, not a routine.
• Build only against Flarum's documented Extender/API surface. Any direct query against Flarum tables is a defect, not a shortcut.
• Keep the forum on a separate database and separate credentials. Cross-database joins are how the two systems become inseparable and un-upgradeable.
• Serve at community.example.com. Path-based mounting introduces asset and routing edge cases for the SPA that are not worth the elegance.

Sequencing Identity first, always. Every subsequent phase assumes a single user identity across both systems; deferring SSO means retrofitting user mapping into imported content later, which is the most common way these projects stall. Defer writes until reads are stable, and defer the historical import until the content model is settled — importing into a schema that 2.0 will reshape is rework by design.

Operational Impact

Maintenance You are now operating two PHP applications with coupled PHP runtime requirements but decoupled release cadences. Budget 0.15–0.25 FTE ongoing for a single-instance forum: core minor upgrades quarterly, extension compatibility checks each cycle, dependency security patching, and asset rebuilds. The 2.0 transition is a discrete project (est. 3–5 weeks including extension replacement), not a maintenance task — plan it, don't absorb it.

Support MIT license, no commercial vendor, no SLA. Support is the community forum and GitHub issues, with best-effort response. For anything user-facing and revenue-adjacent, that means your team is tier 1. Escalation paths for a broken SSO extension at 2am are: read the extension source, or disable it. Staff accordingly, and prefer core functionality over extensions in any user-critical path.

Scaling PHP-FPM horizontal scaling works; the forum is stateless behind Redis for cache/session. Realistic ceilings: comfortable to low hundreds of thousands of posts with tuned caching; beyond that, search latency and topic-list rendering degrade, and you are into Elasticsearch-style external indexing and read replicas. The SPA's client-side payload grows with extension count — keep the extension surface minimal for both security and performance reasons. Multi-region is not a supported story; single-region with backups is the honest posture.

Failure modes

Ramp-up A competent Laravel engineer becomes productive in Flarum core in roughly 1–2 weeks, and productive in the Extender/extension model in 3–4 weeks. The learning curve is not steep but it is non-transferable — that knowledge is single-purpose and leaves with the engineer. Recommend two engineers cross-trained, and a written runbook covering upgrade, rollback, SSO recovery and restore. Frontend work inside Flarum requires Mithril, which is a genuinely separate skill from Vue/React and should be scoped as such rather than assumed.

TPM recommendation: pursue this as a standalone, SSO-bridged community annex on the existing PHP/MySQL substrate. Reject any proposal that frames it as a Laravel package to embed, that shares the Laravel database, or that requires the forum to own identity. Underwrite only core APIs, pin versions, and fund the 2.0 upgrade as a line item now rather than discovering it.