javer/influxdb-admin-bundle
Javer InfluxDB Admin Bundle provides a web-based admin panel for InfluxDB inside Symfony/PHP applications. Browse databases and measurements, run queries, and inspect time-series data from one convenient backend interface, reducing the need for separate InfluxDB tooling.
Reality check before you composer require anything: this is a Symfony bundle (Javer\InfluxDB\AdminBundle) built on SonataAdminBundle, not a Laravel package. There is no service provider, no config/influxdb-admin.php, no Artisan integration. In a pure Laravel app it will install and sit inert. Symfony 7 support (v2.5.0) does not change that — it widens the Symfony range, not the framework scope. You have two honest paths:
influxdb/influxdb-php directly.Minimal Symfony-host steps (targeting Symfony 6.4 LTS or 7.x, with SonataAdminBundle 4.x):
composer require javer/influxdb-admin-bundle
composer.json before assuming compatibility.config/bundles.php.src/DependencyInjection/Configuration.php first — the bundle has essentially no documentation, and the real config keys live there, not in the README.sonata_admin has a dashboard + security configured. This bundle only adds an admin panel on top; it does not bootstrap Sonata for you.bin/console cache:clear, then hit /admin.Where to look first, in this order:
README.md (short, likely incomplete)src/DependencyInjection/Configuration.php — the only source of truth for config keyssrc/Admin/*.php — which model manager it binds to, which routes it exposesResources/config/*.yaml (or config/services.php on newer versions) — service IDs and sonata.admin tagsResources/views/ — the templates you'll overrideFirst use case: read-only browsing of measurements and their tags/fields inside the Sonata dashboard. Treat it as an inspector/explorer, not a CMS. Editing points through a Sonata form is technically possible and almost never what you want.
Read-only admin in production (the default posture). Restrict the admin's routes to list and show, disable create/edit/delete via configureRoutes() or by overriding getRoutes(), and put the whole /admin prefix behind a firewall role. InfluxDB points have no stable primary key — delete/edit flows are footguns.
Register the admin as a Sonata service. Tag it sonata.admin, set manager_type to whatever ODM manager the bundle ships, and set group, label, and pager_type. On Symfony 6.4/7.x with Sonata 4.x the service definition is usually PHP-attribute or YAML based; use bin/console debug:container --tag=sonata.admin to see what the bundle registered versus what you added.
Multi-cluster / multi-database. Define one admin service per connection (or per database/retention policy), each wrapping a distinct ODM manager. Group them in Sonata so operators don't confuse prod telemetry with staging.
Datagrid filters are your whole UX. In configureDatagridFilters, add a mandatory-ish time-range filter and tag filters. Set max_per_page low. A "show all measurements, all time" list view is the single most common way this admin will take down a dashboard — see Gotchas.
Laravel equivalent (the realistic day-to-day pattern).
// AppServiceProvider
$this->app->singleton(InfluxDB\Client::class, fn () => new InfluxDB\Client(
config('influx.host'), config('influx.port'),
config('influx.user'), config('influx.password'),
));
Then expose the same surfaces the bundle exposes:
influx:measurements, influx:tags --measurement=..., influx:query "SELECT ...".Shared configuration. Keep Influx credentials in env and inject the identical values into both the Symfony admin and the Laravel app. Don't let the admin bundle grow the connection string.
Write-back for reporting. The same client/ODM can write scheduled aggregates as new measurements; those then become browsable in the admin. This is the one pattern where the bundle earns its place long-term.
Maintenance signal is still weak, but improving. v2.5.0 (Symfony 7 + PHP 8.1) shows the bundle is being kept alive rather than abandoned. That said: low adoption, minimal docs, and a tiny release history mean you should still pin an exact version, read the source before trusting it, and be ready to fork (MIT makes that cheap). Symfony 7 support is framework compatibility — it says nothing about InfluxDB API evolution or Sonata 5.x. Check the composer.json constraints yourself rather than inferring from release notes.
InfluxDB version compatibility is the #1 trap — and v2.5.0 does not touch it. The InfluxDB ODM/client lineage targets the InfluxDB 1.x HTTP API (/query with db= and optional auth). InfluxDB 2.x requires org/bucket/token; InfluxDB 3.x is a different API entirely. The Symfony 7 bump modernises the container wiring, not the storage protocol. Verify your server version before installing. If you're on 2.x/3.x, this bundle is not your answer.
Symfony ↔ Sonata version matrix. Symfony 7 support means the bundle now spans Symfony 6.4 and 7.x. SonataAdminBundle 4.x vs 5.x changed admin service definitions and route configuration significantly, and Symfony 7 support does not imply Sonata 5.x support. A stale constraint against a new Sonata yields confusing "service not found" errors rather than a clean conflict resolution failure. Run composer why-not if install fails silently into an old tag.
Don't downgrade to accommodate PHP. If your app is on PHP 8.0 and you grab an older tag to install, you are getting pre-Symfony-7 code paths that may not be compatible with your actual Symfony version. Upgrade PHP rather than back-revving the bundle.
Influx is not relational — Sonata assumes it is. No auto-increment IDs, no joins, no transactions. Datagrid counts and pagination translate into expensive COUNT/LIMIT queries whose cost scales with series cardinality, not row count. On a high-cardinality bucket the list page can time out. Always time-bound queries; never offer an unbounded "all data" view.
Schema drift breaks filters. Measurement fields are schema-less; the same field can be int in one point and string in another. Property mapping is convention-based, so a missing tag becomes null and a type change silently breaks filter comparisons. Expect to debug filter behaviour against raw InfluxQL, not against the UI.
Config quirks. After any config change run cache:clear — Symfony config is compiled, and this is especially true on Symfony 7 where the container is more aggressively cached. Use debug:container --tag=sonata.admin and debug:container javer to find the actual service IDs, since the bundle's naming isn't documented. Watch YAML load order in config/packages/.
Debugging. Symfony's profiler will not show InfluxDB HTTP calls unless you wrap the client with a logging HTTP client/middleware. Log the generated InfluxQL, then reproduce it with curl against /query. 401 = auth/credentials, 400 = malformed query (usually escaping or a reserved word in a measurement name).
Extension points you'll actually use. Override templates at templates/bundles/JaverInfluxDBAdminBundle/...; decorate the admin service rather than editing vendor code; subclass the admin class for custom actions; write custom Sonata datagrid filters that emit InfluxQL for tag-based slicing.
Do not shoehorn it into Laravel. There is no ServiceProvider adapter, and v2.5.0 did not add one. Don't add it to a Laravel composer.json and expect app(...) to resolve anything. If both frameworks share a monorepo, keep the bundle's classes out of Laravel's autoload path.
Test against a real server. Mocking the HTTP client gives false confidence about query semantics, retention policy behaviour, and cardinality cost. Run InfluxDB 1.x in Docker (or testcontainers) in CI — matching the major version of your production server.
How can I help you explore Laravel packages today?