Statamic Business Mode Laravel Package

Getting Started

Install the addon with Composer from your Statamic project root:

composer require pattern/statamic-business-mode

The package is a Statamic addon, so installation is a two-step affair: Composer pulls it in, then the addon's service provider registers itself via Laravel's package discovery. If discovery is disabled in your project, add Pattern\StatamicBusinessMode\ServiceProvider to config/app.php manually.

Where to look first:

1. vendor/pattern/statamic-business-mode/src/ServiceProvider.php — this tells you what the addon actually registers (config, middleware, tags, CP nav, routes). Because the package has no docs site and a single 2021 release, reading the provider is the fastest way to understand its surface area.
2. Publish the config so you can see the toggle names and defaults:

   php artisan vendor:publish --tag=statamic-business-mode-config
   

   The published file (typically config/statamic/business-mode.php or config/business-mode.php) is where the mode is enabled/disabled and where any allow-lists live.
3. vendor/pattern/statamic-business-mode/src/ for anything middleware-like or a BusinessMode facade/class — that class is usually the single source of truth you'll call from your own code.

First use case: the canonical scenario is a site that is authored in staging but operated in production. You want editors to have the full Statamic control panel on staging, but on production the site should run in a locked-down "business" state — no CP authoring, no live preview, content served as-is. Enable the mode per-environment via .env:

STATAMIC_BUSINESS_MODE=true

…and leave it false (or unset) locally and on staging. That single flag is the leverage point you'll build the rest of your workflow around.

Implementation Patterns

Environment-scoped toggling. The idiomatic pattern is to drive the mode entirely from environment config, never from a CP toggle. Keep STATAMIC_BUSINESS_MODE=false in .env.example, true only in your production environment's .env (or in config/statamic/business-mode.php keyed off app()->environment('production')). This keeps the mode out of the database, so it survives content syncs and is reproducible.

Gate the control panel. If the addon exposes middleware or a route guard, register it on the CP route group so non-admins are bounced while a designated "operator" role can still get in for emergencies. The pattern that works well with Statamic:

// In a service provider or config/statamic/business-mode.php
'allow' => [
    'roles' => ['super', 'operator'],
    'emails' => [env('OPERATOR_EMAIL')],
],

Even if the package doesn't ship exactly this shape, wrap its check in your own gate so the policy lives in one place:

Gate::define('access-cp-in-business-mode', fn ($user) =>
    ! config('statamic.business-mode.enabled') || $user->isSuper()
);

Blade / Antlers conditionals. Surface the mode to templates so you can hide authoring affordances (edit links, "Live Preview" buttons, draft badges) when the site is in business mode. Expose a single helper or view variable rather than sprinkling config('...') calls through templates — a BusinessMode::isActive() call in a view composer pays for itself.

Deployment workflow. Treat the toggle like any other environment difference:

Put the flag in your deploy runbook / Forge or Envoyer "environment variables" screen, not in a manually-edited .env on the box.

Pair with caching and static generation. Business mode pairs naturally with Statamic's static caching — if content isn't being authored, you can lean on the static cache more aggressively. In business mode, trigger a static cache warm on deploy rather than relying on editor saves.

Gotchas and Tips

• Version compatibility is the big one. The last release was May 2021, which puts it in the Statamic 3.0/3.1 era. Statamic 4 and 5 changed service provider conventions, the CP routing, and the addon manifest (statamic key in composer.json). Test against your Statamic version before committing; expect to fork if you're on 4+.
• Zero stars, zero dependents, no docs. Read the source end to end. A 2021 single-maintainer addon may carry assumptions (hardcoded CP path, old Statamic::route() helpers) that no longer hold. Pin the version in composer.json ("pattern/statamic-business-mode": "1.0.*") so an unexpected tag doesn't break production.
• Config caching bites. If you toggle the mode via config, remember php artisan config:cache on deploy — a stale cache will leave the site in the wrong mode. If the addon reads env() directly outside a config file, it will break the moment config caching is on. Verify the provider reads through config(), not env(), at runtime.
• Don't confuse it with Statamic's own "run mode" concept. Statamic 3+ has STATAMIC_CP_ROUTE, STATAMIC_API_ENABLED, and a headless mode; business mode is a separate layer. Overlapping toggles (e.g., also setting STATAMIC_CP_ROUTE to something obscure) compound unpredictably — pick one line of defense.
• Debugging checklist. If the mode "isn't working": (1) php artisan about and confirm the provider is listed; (2) php artisan config:show statamic.business-mode (or whatever key the published config uses); (3) php artisan route:list | grep business to see if middleware actually attached; (4) check storage/logs for provider boot errors, which are common with old addons on new Laravel.
• Extension points. The two reliable ones for a small addon are the published config and the service provider's bindings. If the package registers a singleton or a Blade directive, you can extend it from your AppServiceProvider rather than editing vendor code. If the mode check isn't abstracted, that's your first contribution upstream (or a local patch via composer-patches).
• Fallback plan. Given the maintenance risk, isolate the mode check behind your own tiny App\Support\BusinessMode class that delegates to the package. If the addon rots, you swap the implementation in one file and drop the dependency without touching templates or middleware.