Alt Inbound Laravel Package

Technical Evaluation

Architecture fit

• This is a Statamic addon, not a framework-agnostic Laravel package. It assumes Statamic's addon lifecycle (service provider registration, addon.yaml manifest, optional Control Panel routes/views, publishable config) and will only load meaningfully inside a Statamic application. In a plain Laravel app there is no supported integration path — the package name and description both scope it to Statamic.
• Where Statamic is present, the fit is structurally clean: request-time IP blocking is naturally implemented as HTTP middleware pushed onto the web group, running in the same PHP process with no new infrastructure, no sidecar, and no external service dependency.
• The open question is where the enforcement point lives. Middleware-level blocking sits behind web server, CDN, and any static/page cache, so the actual security boundary is only as good as the deployment topology around it.

Integration feasibility

• Low technical effort to install: composer require alt-design/alt-inbound, Statamic auto-discovers addons, config is published, middleware registered. A competent Statamic developer can get a working proof-of-concept in under a day.
• Real feasibility risk is not installation but correctness of IP resolution. Any useful evaluation must confirm the addon consumes Laravel's TrustProxies middleware output ($request->ip()) rather than parsing X-Forwarded-For or CF-Connecting-IP itself. Hand-rolled header parsing is the single most common defect in this package category and creates a trivially bypassable control.
• Secondary feasibility checks: IPv6 and CIDR-range support, allowlist/whitelist semantics, storage backend (flat YAML vs. database vs. cache), and whether blocked requests are logged.

Technical risk

• Adoption risk (high): 3 stars, 0 dependents, single maintainer. This is effectively unreviewed code in a security-sensitive position. Treat it as a code sample to audit, not a vetted dependency.
• Metadata risk (medium): the reported last release of 2026-10-26 is a future date, which indicates either a data anomaly in the registry or a release-tagging irregularity. Do not take compatibility claims at face value — inspect tags and composer.json constraints directly.
• Correctness risk (high): IP blocking is deceptively simple. Trusted-proxy handling, IPv6 normalization, CIDR matching, and behavior under static caching / full-page CDN caching determine whether the control works at all or merely appears to.
• Blast-radius risk (medium): a self-inflicted Control Panel lockout, or a fail-closed default on a storage error, can take a site down. Fail-open vs. fail-closed behavior must be an explicit, tested decision.
• Supply chain risk (medium): low-star, low-audit packages in the request path are a soft target. Pin the exact version, review the diff, and vendor or fork if adopted.

Key questions

1. Which Statamic majors (4/5/6?) and Laravel/PHP versions are supported, and are the constraints accurate versus the released tags?
2. Does it call $request->ip() (trusting TrustProxies), or does it parse forwarding headers itself? Does it document Cloudflare/ALB/Fastly setups?
3. Does it support IPv6 and CIDR ranges, or only exact-match IPv4 strings?
4. Where is the blocklist persisted — flat file, database, or cache — and is it safe for multi-node deployments?
5. Is there an allowlist, and is the Control Panel / authenticated users exempt by default?
6. What happens on storage or cache failure: fail-open or fail-closed?
7. Are blocked requests logged, and is there any rate-limit or auto-ban capability, or is it manual list management only?
8. Is there a test suite, and does it cover proxy/header edge cases?
9. Does it interact correctly with Statamic's static caching and Laravel's route/page cache?
10. What is the maintainer's responsiveness and release cadence over the last 12 months?

Integration Approach

Stack fit

• Eligible only for Statamic-backed sites (typically Laravel 10/11/12, PHP 8.1+). Confirm the exact matrix before committing.
• For any Laravel-only application, or any site where the real requirement is abuse/DDoS mitigation, this addon is out of scope. Use edge controls (Cloudflare WAF, nginx deny, fail2ban, CrowdSec) or a purpose-built Laravel firewall package instead.
• Best-fit profile: small-to-mid Statamic sites with no WAF, where editors want to manage an IP blocklist from the Control Panel without touching nginx config or a CDN dashboard.

Migration path

1. Inventory existing controls first — CDN/WAF rules, web-server denies, fail2ban, application-level throttles. Most deployments already have partial coverage; the addon should be positioned as a management layer for editor-driven blocks, not a replacement for edge filtering.
2. Export current blocklists from those systems; normalize to a single canonical format (IPv4, IPv6, CIDR) so you can diff behavior after cutover.
3. Install in staging with a published config, seed a test list, and verify from a non-production source IP.
4. Keep existing edge rules in place; layer the addon beneath them. Retire nothing until the addon has run through at least one full traffic cycle.

Compatibility

• Verify against the specific Statamic minor version in use; addon compatibility often lags Statamic majors by weeks-to-months.
• Verify the proxy topology end-to-end: if a CDN or load balancer terminates TLS, TrustProxies must be configured correctly before this addon's middleware is meaningful. Test with spoofed X-Forwarded-For headers to confirm the addon cannot be bypassed.
• Verify behavior with static caching enabled — on a fully cached page the middleware may never execute.

Sequencing

1. Week 1 — Spike and audit: read the middleware source, confirm IP-resolution approach, confirm storage model, run the test suite, check open issues and release history. Gate decision here.
2. Week 2 — Staging validation: install, configure, test proxy spoofing, IPv6, allowlist, fail behavior, and CP lockout recovery.
3. Week 3 — Production, observe-only: deploy with an empty blocklist and logging enabled; confirm it correctly identifies real client IPs across CDN, LB, and direct traffic.
4. Week 4 — Enable enforcement: populate from the migrated list, with a documented allowlist for office/VPN/admin ranges.
5. Post-rollout — Decide: keep as dependency, fork and own, or replace with a ~150-line internal middleware (this is a genuinely small amount of code to own).

Operational Impact

Maintenance

• Realistic assumption is fork-and-own. The MIT license permits it, and the code surface is small. Budget the cost of internal ownership — security-sensitive middleware needs periodic review, not just "it still installs."
• If kept as an upstream dependency, pin to an exact version in composer.lock, subscribe to releases, and re-audit on every bump. Do not allow unconstrained ^ ranges on a package in the request path.
• Track Statamic major upgrades explicitly; addons in this tier commonly go unmaintained across a Statamic release.

Support

• Community-only, low-volume. Expect no SLA and potentially slow issue response. The internal escalation path is you.
• Mitigate by maintaining a short internal runbook: how to add/remove an entry, how to recover from a self-lockout (direct file or DB edit, or env-level bypass), and who is authorized to change the list.

Scaling

• Per-request cost is one lookup; negligible if backed by cache or a small in-memory list, but confirm the lookup is not a file read or DB query on every request in a high-traffic deployment.
• Multi-node deployments require a shared backing store (database or Redis). A flat-file blocklist will diverge across nodes and is unsuitable beyond single-server setups.
• Control Panel edits must be visible across nodes without a deploy — validate cache invalidation.
• This addon does not scale as a DDoS defense. It is an administrative list of known-bad IPs; volumetric traffic must be handled upstream.

Failure modes

• Proxy misconfiguration: spoofable client IP → control is cosmetic. Highest-probability failure.
• Cache/CDN bypass: blocked IPs still served by edge or static cache; enforcement appears to work in testing and not in production.
• Self-lockout: an overly broad CIDR entry or an admin's dynamic IP blocks Control Panel access. Recovery requires file/DB-level intervention.
• Fail-closed on storage error: a corrupt or unreadable blocklist returns 403 for all traffic.
• Fail-open on storage error: the control silently disappears; nobody notices until an incident review.
• IPv6 gap: exact-match IPv4-only matching leaves dual-stack clients unaffected by an IPv4 block.
• Stale list drift: manual lists decay without ownership and a review cadence.

Ramp-up

• Installation and basic configuration: roughly half a day for a developer already fluent in Statamic.
• Safe production ownership: one to two weeks of elapsed time, dominated by proxy/IP correctness validation, allowlist design, and runbook authoring — not by the package itself.
• Non-Statamic developers should add a day for Statamic addon conventions (service providers, middleware registration, publishing, CP scaffolding).

Overall TPM position: the problem is real — Statamic sites frequently lack a convenient, editor-manageable abuse control, which explains the mid-range opportunity score. The package is not yet a defensible dependency at 3 stars, 0 dependents, and an anomalous release date. Recommended posture: evaluate as a reference implementation, adopt only after a source audit, expect to fork, and always deploy it behind — never instead of — edge-level filtering.