Shopware Maintenance Laravel Package

Product Decisions This Supports

• Build vs. buy for maintenance mode: Shopware ships a basic maintenance mode, but teams routinely need more — branded maintenance pages, IP allow-listing so QA/stakeholders can preview the live store, per-sales-channel toggles (e.g., take B2B offline while B2C stays up), and scheduled windows. This package (now at v4.0.0) is a candidate to satisfy that need without allocating sprint capacity to build and maintain a custom plugin.
• Release and migration readiness: Planned downtime for Shopware upgrades, plugin rollouts, data migrations, or infrastructure changes becomes a repeatable operational step rather than an ad-hoc config change. Useful input to release checklists and on-call runbooks. v4.0.0 specifically hardens this path for teams running New Relic — plugin sync no longer crashes under that APM, which matters if observability tooling sits in front of your release process.
• Incident response and peak-event planning: A fast, safe way to put the storefront into a controlled maintenance state during outages or before Black Friday / launch windows, with a customer-facing page that preserves brand trust instead of a raw error.
• Roadmap scoping for storefront operations: If maintenance UX keeps surfacing in support tickets or launch retro notes, this package anchors the "minimum viable" scope — freeing the team to prioritize revenue-generating features instead of operational plumbing.
• Platform standardization: For agencies or multi-shop operators on Shopware, adopting one known extension across projects reduces bespoke code per client and simplifies handover and support.
• Upgrade-window decision (new): v4.0.0 is a major version bump arriving without a migration guide or breaking-change list in the release notes. Treat the upgrade itself as a small roadmap item: scoped sandbox upgrade, smoke test, then rollout — do not treat it as a passive patch-level dependency update.

When to Consider This Package

Consider it when all of the following hold:

• You are on Shopware 6 (this is a Shopware plugin, not a general Laravel package — verify version compatibility against your Shopware release before committing).
• Your requirements exceed core maintenance mode: IP whitelisting, per-sales-channel control, custom maintenance templates, or scheduling.
• You have a small platform/ops team without spare capacity to own a custom plugin long-term.
• You accept a low-adoption dependency (19 stars at last check) and can absorb the risk — mitigated by the fact that it is a small, inspectable plugin and the last release is recent (v4.0.0, with v3.0.0 preceding it).
• You run New Relic (or may adopt it): v4.0.0's headline fix removes a plugin-sync crash caused by that APM. If you already run New Relic on the shop, this release is the minimum viable version — earlier majors carry a known failure mode.

Look elsewhere or build in-house when:

• You are not on Shopware, or you need maintenance at the CDN/edge layer (Cloudflare, Fastly, load balancer) rather than in-application — edge handling is generally more resilient when the app itself is unhealthy.
• You require a vendor SLA, commercial support, or security review — a small OSS extension will not provide this; budget for internal code review and a fork/fallback plan.
• 0 dependents matters to your procurement: note that Shopware plugins are typically distributed via the Plugin Manager/Store rather than Composer, so dependents count understates real usage — but it also means limited community validation.
• You need deeply customized maintenance behavior; at that point the customization cost approaches building it yourself.
• You cannot absorb a major-version upgrade cycle: v4.0.0 shipped with a two-line changelog (one fix, one docs addition) despite being a major bump. That likely signals internal/structural change rather than feature work — a fine thing to consume, but only after you've reviewed the diff and confirmed compatibility on your Shopware version.

How to Pitch It (Stakeholders)

For executives: A low-cost, low-risk extension that gives us professional maintenance-mode control on our Shopware storefront — branded downtime pages, the ability to keep the site up for internal testers while customers see a maintenance notice, and per-channel control. It protects revenue and brand during releases and incidents, and it costs us far less than building and maintaining this ourselves. The latest release (v4.0.0) also resolves a conflict with our monitoring stack, which removes a real operational sharp edge. The main caveat is unchanged: it is a small open-source project, so we treat it as a vetted dependency with an internal fallback rather than a strategic platform bet.

For engineering: Actively maintained. v4.0.0 fixes a plugin-sync crash triggered by New Relic and adds contributor docs (CLAUDE.md); two first-time contributors landed changes, which is a mild positive signal on bus factor. It is a major version bump with no documented breaking changes, so: read the v3→v4 diff before upgrading, pin the version in the plugin config, verify against our Shopware and PHP runtime in staging, and confirm New Relic is not installed in a way that still collides. Note this release adds no new user-facing features — do not expect scheduling/per-channel gaps to be closed by it; if requirements grow beyond its scope, we fork or replace, and the integration cost is low enough that the exit cost is too.