Geoip2 Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for localization and geo-personalization. Whether we default currency, language, shipping estimates, or storefront content by visitor country; whether we gate content or pricing regionally. A GeoIP lookup is the cheapest way to get a first-pass country signal before a user tells us anything.
• Build vs. buy for a small infrastructure concern. This bundle is a thin dependency-injection wrapper over geoip2/geoip2 (MaxMind's official PHP reader). The real build-vs-buy decision is MaxMind database vs. a hosted IP-intelligence API — the bundle itself is a few hundred lines of Symfony config, so the switching cost is low in either direction. The 3.0.0 release does not change that calculus: it is a maintenance release (PHP 8.4/8.5 support, legacy PHP/Symfony dropped, GeoIP v2 support removed, PHPUnit/PHPStan upgrades), not a capability release.
• Roadmap sequencing: is geo-IP a v1 need or a v2 nice-to-have? Geo-IP is usually a supporting capability, not a differentiator. If geo signals only feed analytics enrichment or a soft "suggested region" prompt, it can ship behind a feature flag and be revisited.
• Risk and compliance posture. MaxMind GeoIP2 Lite databases carry attribution requirements and are explicitly not meant for high-stakes decisions (fraud scoring, age gating, legal jurisdiction). Choosing this package commits us to a self-hosted, periodically-refreshed database with a MaxMind account — a small but real operational commitment.
• Architecture alignment — the decisive point. Despite being catalogued alongside Laravel/PHP packages, this is a Symfony bundle, not a Laravel package. It provides Symfony service definitions and bundle config. In a Laravel codebase it delivers no value over the underlying library. The product decision it should drive is "use geoip2/geoip2 directly behind our own thin service," not "adopt a bundle."
• Platform currency as a hidden cost. 3.0.0 explicitly drops support for older PHP and Symfony versions. Adopting it is therefore also a decision to keep the surrounding application on a current runtime; on a legacy stack the bundle is unavailable until an upgrade lands, and each future major will re-impose that constraint.

When to Consider This Package

Consider it if:

• The application is Symfony (not Laravel) and we want GeoIP wired into the container with minimal boilerplate — config-driven database path, autowired reader service, sensible defaults.
• We are already on a current PHP 8.x / modern Symfony line, so the 3.0.0 floor costs us nothing. The maintainer tracking PHP 8.4 and 8.5 is a genuine positive signal about near-term currency.
• We only need country-level lookups from a local MaxMind .mmdb file and are comfortable managing database downloads/refreshes ourselves.
• We want a small, MIT-licensed, single-purpose dependency we could realistically read end-to-end and fork if the maintainer goes quiet.

Look elsewhere if:

• We're on Laravel. This bundle's core value (bundle registration, DI extension) does not apply. Use geoip2/geoip2 directly in a service provider, or evaluate torann/geoip / stevebauman/location if we want Laravel-native facades and multi-driver support.
• We are pinned to an older PHP or Symfony version. 3.0.0 drops legacy runtimes and GeoIP v2 support, and the upgrade guide implies a breaking migration. For a convenience wrapper over a library we could call in a few lines, that upgrade cost is hard to justify.
• Maintenance risk is unacceptable. 1 star, 0 dependents, and a single maintainer is a weak signal. There is no meaningful community to catch regressions; a composer update is effectively a code review we do ourselves. Note also that this is a fork of gpslab/geoip2, i.e. the project has already changed hands once. A version 3.0.0 with PHPUnit/PHPStan bumps is housekeeping, not evidence of a roadmap, and the release notes' rough edges ("Upgrade PHP Unot") are a small but real signal about release discipline.
• We need city/ISP/anonymizer accuracy or managed updates. MaxMind's paid web service or a commercial IP-intelligence vendor is the right call; a self-hosted Lite DB plus a community wrapper is the wrong tool for anything revenue- or compliance-sensitive.
• We expect high request volume or need low latency. Caching, circuit-breaking, and fallback behavior are ours to build; the wrapper won't help.
• Privacy/consent constraints are strict. IP-based geolocation can be personal data under GDPR. We need a documented lawful basis, retention policy, and an easy "no geo" fallback — none of which a bundle provides.

How to Pitch It (Stakeholders)

To executives: We re-evaluated a community GeoIP integration after its 3.0.0 release. Nothing in that release changes the recommendation: it is a maintenance milestone — PHP 8.4/8.5 support, removal of legacy PHP/Symfony and GeoIP v2 support, and tooling upgrades — with no new capabilities. The technical recommendation stands: adopt MaxMind's official PHP library directly and wrap it in ~50 lines of our own code, rather than depend on a single-maintainer Symfony bundle with essentially no adoption and a history of one fork already. Rationale: the bundle is a convenience layer, not a capability layer — the GeoIP database does the work, and the wrapper is trivially replaceable. This keeps us on a well-maintained foundation, avoids lock-in to an unmaintained dependency, and preserves the option to switch to a commercial IP-intelligence API later without touching feature code. Cost impact: near zero in engineering time; the real cost is a MaxMind account and a scheduled database refresh, which we should scope as ongoing operational overhead, not a one-time build. Recommendation: proceed with geo-IP as a supporting capability, built on the official library, delivered behind a feature flag.

To engineering: Treat huluti/geoip2-bundle as prior art rather than a dependency. It confirms the expected shape of the integration — a configured reader service, a database path, a thin domain wrapper returning country/region — and we should replicate that shape in our own service class. The 3.0.0 release is a fork-lineage maintenance bump: it modernizes the supported runtime (PHP 8.4/8.5) and tooling but adds no API surface, and it will force a breaking upgrade on anyone who adopted it — exactly the kind of churn we avoid by owning the wrapper. Pin geoip2/geoip2, define a GeoResolver interface with a MaxMind implementation and a null/cached decorator, keep lookups out of the request hot path where possible, and log misses explicitly so we can measure accuracy before any user-facing feature depends on it. Do not let geo data drive eligibility, pricing, or access decisions in v1.