winter-bridge/bridge
Bridge connects Winter CMS with your Laravel/PHP application, offering a lightweight integration layer for shared configuration, components, and services. Install via Composer and wire it into your existing stack with minimal changes.
Architecture fit. winter-bridge/bridge is a thin integration layer that extends Laravel's authentication stack so a Laravel application can resolve identities against Winter CMS (the Laravel-based fork of October CMS). Architecturally it occupies a narrow but well-defined seam: it plugs into Laravel's Auth guard/provider contract and points user resolution at Winter's backend user model and related plugins (e.g., RainLab.User). It is a fit only for teams running both a Laravel app and a Winter CMS instance that must share a single identity source. It is not a general-purpose auth package and adds no value to a Laravel-only stack.
Integration feasibility. Distribution is Composer-based, so adoption mechanics are standard: composer require, register the service provider, and wire a custom guard/provider in config/auth.php. The surface area is small, which keeps the integration tractable. The 1.0.1 release does not change this: it is a patch-level compatibility fix ("Aligned the Authmanager with the current WinterCMS updates"), not a feature or documentation release. The repository still ships with minimal public documentation and a single maintainer (Teranode), so expect to read source rather than follow a guide. A time-boxed spike (2–3 days) against our exact Laravel and Winter versions remains the realistic first step before committing.
Technical risk. High, driven by lifecycle signals rather than code complexity, though the signals have shifted modestly with 1.0.1:
AuthManager had to be realigned with current Winter CMS updates. That is direct evidence the package is coupled to Winter's auth internals and that upstream Winter changes do break it. We should expect the same class of breakage on future Winter upgrades, with fix latency measured in months-to-years rather than days.Key questions. (1) Which exact Winter CMS version does 1.0.1 target, and does it regress against earlier Winter releases? (2) Which Laravel versions and PHP versions (8.2+) are supported — is there a support matrix or CI? (3) Is identity shared via a common database table, session cookies, or token exchange — and what is the cookie/domain model? (4) Does it preserve Winter's password hashing and user lifecycle events, or require dual-writes? (5) What is Teranode's maintenance commitment now that a release has landed, and is the license permissive enough to fork? (6) Has anyone run this in production, and can we get a reference?
Stack fit. Appropriate only where the target architecture is explicitly "Laravel app + Winter CMS sharing one user base." If identity can instead be centralized (Laravel as the IdP, Winter as a relying party via OAuth2/OIDC/SAML, or laravel/socialite + a standard provider), that path is preferable and removes this dependency entirely. The bridge is the right tool only when a shared-database, single-sign-on-across-both-apps model is a hard requirement and a full IdP migration is out of scope. 1.0.1 does not change this calculus — it restores viability, it does not create it.
Migration path. Treat the package as a starting point, not a dependency. Recommended path: (1) vendor the package into our monorepo (composer path repo or fork under our org) so we control patching, branching from 1.0.1 rather than the 2022 tag; (2) validate against our pinned Laravel/Winter versions in a staging environment; (3) replace the package's config with our own guard/provider definitions; (4) add integration tests around login, logout, session persistence, and password reset; (5) only then promote to production behind a feature flag.
Compatibility. Pin exact versions of Laravel, Winter CMS, and PHP in composer.json and lock them. Critically, pin Winter CMS to the release that 1.0.1 was aligned against — the patch explicitly tracks "current" Winter, so adjacent Winter versions are unverified in both directions. Run a compatibility matrix (at minimum: our current LTS plus the next minor) in CI. Because upstream cadence is unpredictable, version drift is guaranteed — budget for a quarterly compatibility review or an explicit "no upgrades without re-validation" policy, and treat any Winter CMS upgrade as a mandatory re-test of the auth path.
Sequencing. Sequence as: identity spike (against 1.0.1) → fork/vendor → guard/provider wiring → session and cookie model validation → security review of the auth path → staged rollout. Do not interleave this with unrelated Laravel or Winter CMS upgrades; isolate the change so failures are attributable.
Maintenance. Still effectively self-maintained from day one. 1.0.1 is a welcome sign of life and reduces the "dead package" risk, but with one maintainer, a multi-year gap before this patch, and no stated cadence, we should continue to assume ownership of the code, the tests, and the security posture. Estimate ~0.1–0.2 FTE ongoing for compatibility tracking and patching, plus a defined owner on the identity/platform team. Discount this only if a second release lands within a normal maintenance window.
Support. Community-only, no SLA, no vendor escalation path. Internal support means the platform team owns incident response for auth failures. Document a runbook and a fallback (e.g., disable the bridge, revert to native Laravel auth) before go-live.
Scaling. The bridge itself is thin and unlikely to be a throughput bottleneck; scaling characteristics are inherited from the underlying database, session store, and Laravel's auth cache. The real scaling concern is organizational: shared user schema between two applications creates a coordination cost as either side evolves its user model.
Failure modes. Watch for: (a) silent auth bypass from a misconfigured guard — mitigate with negative tests; (b) session/cookie domain mismatch causing intermittent logouts across subdomains; (c) password hash or user-schema drift after a Winter or Laravel upgrade — this is the failure 1.0.1 exists to fix, so treat it as the highest-probability event; (d) breakage on PHP/Laravel/Winter upgrades with unpredictable upstream fix latency; (e) data integrity issues if both apps write to the user table without a single source of truth. Each warrants an alert and a documented rollback.
Ramp-up. The code surface is small, so initial ramp is days, not weeks — but it requires developers fluent in both Laravel auth internals and Winter CMS conventions, which is a narrow skill set. Plan ~1–2 developer-weeks for PoC, fork, hardening, and tests before production readiness, and factor in knowledge concentration risk if only one engineer understands the bridge.
TPM recommendation. Do not adopt as a live, unmodified dependency. The substantive position is unchanged, but the framing shifts: 1.0.1 makes this a viable build-or-replace decision rather than a likely-dead end. Either (1) pursue a standard IdP/SSO approach that eliminates the need for a bridge, or (2) fork and vendor the package starting from 1.0.1, with an explicit ownership and compatibility-review commitment. Do not read a single compatibility patch as a maintenance guarantee — the release note itself confirms the package breaks on Winter auth changes and that the maintainer relies on users to report issues. Zero dependents and a single maintainer keep this in build-or-replace territory, not buy-and-forget.
How can I help you explore Laravel packages today?