Hosting Laravel Package

Product Decisions This Supports

• Environment-tier model as a first-class product concept. The bundle forces three named config keys — tier (production/staging/development), project, and installation — instead of scattered APP_ENV checks. That's a decision you can adopt regardless of stack: standardize a tier vocabulary and make it a config contract every service reads, so "what tier is this?" is answerable without reading code.
• Build vs. buy for observability plumbing. The feature set (an uptime-monitor HTML comment injected into every HTML response, a TrackJS snippet gated by tier, a hosting_tier() helper for conditional template logic) is roughly a day of engineering. The package's real value is the decision record: it proves these are small, reusable concerns worth centralizing rather than re-implementing per project.
• Feature gating and progressive rollout. Tier-based gating (isInDevelopmentTier, hosting_tier()) supports roadmap decisions like "canary to staging before production" and "never ship debug tooling to production." Low cost, high leverage if you have >2 environments.
• Multi-project / multi-installation products. project + installation (a unique technical key) is a lightweight tenancy model for SaaS or agency portfolios — useful for correlating uptime checks and error reports per customer installation without standing up a service registry.
• Scope boundary: config and instrumentation, not hosting. This is not infrastructure. It does not provision, scale, or manage DNS. Use it to decide what your app knows about where it runs, and keep the actual hosting decisions in IaC.
• Ecosystem signal, not product signal. 1 star, 0 dependents, README-and-releases-only maturity, and an internal-origin (Becklyn) Symfony bundle. Treat it as a well-shaped reference implementation, not a dependency bet.

When to Consider This Package

Consider the pattern (strongly) if:

• You run three or more environments and keep re-writing if (app()->environment('production')) in views and middleware.
• You want uptime monitoring wired up without per-project DevOps tickets — an HTML comment plus a monitor check is the cheapest possible signal.
• You sell to or operate multiple installations and need a stable, non-secret identifier per deployment for logs and alerting.
• You want error tracking embedded only where it belongs, without a second config system.

Look elsewhere — or don't adopt the code at all — if:

• You're on Laravel. This is a Symfony bundle. There is no Laravel service provider, no Blade directive, no config/hosting.php. Adopting it means pulling Symfony DI/HttpKernel pieces into a Laravel app to use ~50 lines of logic. That is a net-negative trade; copy the idea instead.
• You use Twig-free templating — hosting_embed_monitoring() has no Blade equivalent, so you're writing it anyway.
• You already run Sentry/OpenTelemetry/IaC with environment metadata; the overlap is near-total.
• Your installation identifiers must be dynamic (UUIDs, per-tenant generation) rather than deploy-time static config.
• Your org's rule is "no single-maintainer, low-signal dependencies in production." One star and zero dependents fails most dependency-review gates, correctly.

Decision rule: adopt as a reference spec and reimplement as ~150 lines of Laravel middleware + a Blade directive + a config/hosting.php. Only vendor the package itself if you are genuinely on Symfony and already use the Becklyn asset bundle.

How to Pitch It (Stakeholders)

Executives (one paragraph): "This is a small Symfony bundle that centralizes three things we currently do by hand: telling the app which environment it's running in, injecting an uptime-monitor marker into HTML, and loading error tracking only in production. It's not a platform — it's a template. My recommendation is not to take a dependency on it (one maintainer, no downstream users, Symfony-only), but to copy its config model — tier, project, installation — into a ~1-day internal implementation. That gets us consistent monitoring across every project and removes a recurring class of 'why didn't staging show up in the dashboard' tickets, with no vendor risk."

Engineering (the pitch): "Three config keys, one service, two template helpers. We mirror it in Laravel: config/hosting.php for tier/project/installation, a global middleware that appends the uptime comment to HTML responses (skip BinaryFileResponse equivalents and anything without a Content-Type), and a @hostingMonitor Blade directive that no-ops outside production/staging. Reuse their validation of tier names and their listener-ordering lesson (inject last, after other listeners have shaped the response). Roughly a day of work, no new dependencies, and it kills the env() calls scattered through our views."

Product framing for the roadmap: treat tier as a product primitive, not an ops detail — it's what lets us ship risky features to staging first, keep debug tooling out of customer-visible HTML, and give every customer installation an identifier that support and monitoring can both quote.