Firewall Laravel Package

Product Decisions This Supports

• Adopt/upgrade decision for bot and crawler verification. v2.38.0 makes reverse-DNS verification bounded and predictable: a slow resolver costs ~300 ms rather than up to 10 seconds. This directly supports approving the upgrade or piloting the package where crawler allowlisting (e.g., search engine bots, partner integrations) is a product requirement and worker starvation is a known operational risk.
• Build vs. buy for lightweight request filtering. The package remains a self-hosted Laravel/PHP firewall with config-as-code, linting (firewall-check --lint), and diagnostics (firewall-doctor). It is a reasonable buy/adopt alternative to building custom middleware for crawler verification, IP trust, and allow/block rules—especially if the team is already on Laravel and wants to avoid a full WAF or edge vendor.
• Privacy and third-party dependency choices. The DNS-over-HTTPS provider is opt-in; default behavior uses PHP’s own lookups and sends nothing to a third party. This gives product and compliance stakeholders a clear decision point: keep the default for privacy-sensitive deployments, or opt into Cloudflare/Google/custom resolver when latency and reliability matter more. The docs document who receives visitor address data and what they log, which supports a defensible privacy review.
• SLO and capacity planning. The measured behavior—first verification ~66–93 ms, subsequent ~19–40 ms, and concurrent workers refused in under 1 ms once the circuit breaker trips—informs product SLOs around request latency, worker pool sizing, and timeout configuration (timeout_ms, verify_claim_wait_ms).
• Multi-tenant and multi-config rollout planning. The config-merging change is a breaking change for sites passing multiple configs to Firewall::create(): lists now replace rather than append. This supports a deliberate upgrade plan—audit trusted_proxies, lockdown_allow, verify_suffixes, and included configs—rather than a blind dependency bump.
• Roadmap input for reliability and abuse resistance. Safer verification behavior (at most two forward lookups per address, resolver-scoped verdicts and circuit breakers, 60-second handling of inconclusive lookups) reduces the chance that a malicious PTR record or network blip causes real crawlers to be refused for a day. That supports prioritizing operational resilience over new feature breadth in the near term.

When to Consider This Package

Consider adoption when:

• The product runs on Laravel/PHP 8.1–8.5 and needs request-level filtering without adding an external WAF or edge service.
• Crawler verification is a product or SEO requirement—for example, allowing verified search engine bots while blocking spoofed user agents.
• The team values config-as-code, startup validation, linting, and doctor-style diagnostics over a GUI-driven firewall product.
• Worker latency and resilience matter: the package now avoids unbounded DNS lookups by default and offers an opt-in bounded provider, with circuit-breaking behavior that prevents one slow resolver from exhausting the worker pool.
• Privacy-sensitive deployments can keep the default PHP resolver path, while performance-sensitive deployments can explicitly opt into a DNS-over-HTTPS provider or a self-hosted resolver.
• The team can absorb a small breaking change in multi-config list merging and has a single owner for firewall configuration.

Look elsewhere when:

• The product needs full WAF capabilities, managed rule sets, DDoS protection at the edge, or non-PHP stack support.
• The organization cannot permit any third-party DNS resolution, even opt-in, and cannot run its own resolver—though the default path avoids third-party lookups, the feature’s operational value is reduced.
• The team lacks the capacity to audit and own firewall configuration across environments and tenants, or expects a fully managed turnkey service.
• The deployment depends on multiple configs adding to the same list and cannot easily consolidate lists into one config during the upgrade.

How to Pitch It (Stakeholders)

For executives: This release turns a known operational risk—slow reverse-DNS lookups holding PHP workers for up to ten seconds—into a bounded, measurable cost. Verification now has a configurable time limit, an opt-in DNS-over-HTTPS provider, and a circuit breaker that keeps one bad resolver from affecting everyone. The default remains private: no visitor data goes to a third party unless we explicitly choose a provider. The trade-off is a small configuration change for sites using multiple configs, which we can audit and stage.

For engineering: v2.38.0 adds global.reverse_dns.provider with cloudflare, google, per-rule overrides, and custom resolver support, plus startup validation and firewall-doctor visibility into where lookups go. It also hardens verification semantics and fixes list-merging inconsistencies. The upgrade requires attention only if Firewall::create() receives more than one config: lists now replace rather than append, and an included file’s [] now clears a list. Single-config deployments should see no behavioral difference. PHP 8.1–8.5 are supported; the DNS-over-HTTPS resolver requires the curl extension. Recommend a staged upgrade with config audit, lint, and a short canary period measuring verification latency and breaker behavior.