- How do I install onecentlin/laravel-adminer in a Laravel app?
- Run composer require onecentlin/laravel-adminer, then publish the config file and Adminer front-end with php artisan vendor:publish. Package auto-discovery registers the service provider and the adminer route automatically on Laravel 5 and later. After publishing, review the config, set your preferred middleware and environment restrictions, and open the route in a browser. Total setup is a few minutes; the real work is gating access.
- Which Laravel and PHP versions does laravel-adminer support?
- The package targets Laravel 5 and later and relies on auto-discovery, so it works out of the box on older majors. It predates the most recent Laravel releases, so its composer.json constraints may block installation on newer versions. Check the PHP and illuminate/support constraints against your target version before committing, and be prepared to loosen them in a fork if needed.
- How do I secure the Adminer route in production?
- The default middleware is web, not auth, so anyone who reaches the route gets unrestricted SQL access to the configured connection. Add auth middleware, restrict the route to local and staging environments, and put an IP allowlist in front of it. Treat it as a privileged side door: it bypasses your domain model, authorization policies, and audit logging.
- Can I change the Adminer route path or add my own middleware?
- Yes. The published config file exposes the route prefix and the middleware stack applied to the Adminer route. You can move it off the default adminer path and wrap it with auth, IP restriction, or throttle middleware. Because routes are registered by the service provider, verify the change survives route caching in each environment.
- Which databases can I manage with Laravel Adminer?
- Adminer supports MySQL, PostgreSQL, SQLite, and several other drivers, so it covers the connections your Laravel app already defines. You can point it at any configured connection, including read-only replicas if you define one. Only enable the drivers you actually need and confirm they are exercised in your environment.
- How do I disable laravel-adminer outside local or staging?
- Gate the route behind an environment check or an explicit config flag so it never registers in production, and default that flag to off. Enforce the expectation in CI so a stray env value cannot expose the tool on a deploy. A single forgotten setting is the difference between a convenience and full database compromise.
- Is it safe to run Adminer inside a Laravel app in production?
- Generally no. Adminer operates at the raw database layer, bypassing row-level policies, field masking, and application audit trails, so PII access is invisible to your normal telemetry. The blast radius is the full database the connection can reach. If production access is required at all, put it behind strong authentication, network restrictions, and a documented approval process, or run it as a separate sidecar instead.
- How do I upgrade the bundled Adminer version?
- You inherit whatever Adminer build the package ships, so upgrading means replacing the published Adminer single-file front-end with a newer upstream release and testing it against your config. Adminer has a public CVE history, including SSRF issues, and a low-activity single-maintainer wrapper is unlikely to track upstream quickly. Plan for a fork so you control patch latency, or decouple Adminer from the app entirely.
- What are the alternatives to laravel-adminer?
- Running Adminer or an equivalent as a standalone container or sidecar keeps a privileged database client off your application's attack surface and out of your release cycle. Desktop clients like TablePlus or DBeaver, phpMyAdmin, and managed cloud consoles such as RDS or Cloud SQL offer the same outcome with IAM and audit logging built in. Choose the in-app wrapper only when in-app routing is genuinely simpler for your deployment model.
- Does Laravel Adminer work with route:cache, reverse proxies, and subdirectory deployments?
- Watch for route registration conflicts with route:cache and with any existing adminer path in your app. Adminer's self-referencing URLs are a known friction point behind reverse proxies and when the app is served from a subpath. Also confirm its session and cookie handling does not collide with your app's auth session. Test these cases in staging before promoting.