Laravel Adminer Laravel Package

Getting Started

Install the package with Composer (it is dev-friendly but not require-dev-only, since routes are registered from the service provider):

composer require onecentlin/laravel-adminer

Publish the configuration so you can see and change the route, middleware, and autologin behavior:

php artisan vendor:publish --provider="Onecentlin\Adminer\AdminerServiceProvider"

This creates config/adminer.php. The first thing to look at is that file — it controls the URI (default /adminer), the middleware stack, whether the route is enabled outside local, and autologin. Then hit http://your-app.test/adminer. You get the full Adminer login screen; log in with the credentials from your .env (DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD).

The first real use case: replacing a standalone phpMyAdmin/TablePlus session during local development. You already have a browser tab on the app, so /adminer gives you browse/query/edit access to the same database without copying credentials into another tool or spinning up a container. It is especially handy on ephemeral environments (Sail, Docker, shared dev boxes) where installing a desktop client is friction.

Implementation Patterns

Local-only browsing with autologin. Turn on autologin in config/adminer.php so Adminer pre-fills the current Laravel connection, saving you from retyping DB credentials each session. Pair it with the default local-only guard and you get a one-click "open my dev database" route that never ships to production.

Promote it to staging behind a guard. When you need database access on a shared staging box, change the enabled check in the config and add real middleware:

// config/adminer.php
'middleware' => ['web', 'auth', 'can:view-adminer'],

Register a view-adminer gate limited to admins. This is the pattern that makes the package usable beyond localhost without hand-rolling an access proxy.

Custom route per environment. Use the env override to avoid a predictable path on non-local environments:

ADMINER_ROUTE=_ops/db

Followed by php artisan config:clear and route:clear. Since routes are registered by the service provider, any config change here requires a cache clear to take effect.

Multi-connection workflows. Autologin targets the connection Adminer can resolve (typically the default). If you work across mysql, pgsql, and a reporting replica, keep autologin for the primary and use Adminer's own server/login form for the others. A common pattern is one Laravel app with DB_CONNECTION switched via .env and Adminer used to diff the two data sets.

Docker / Sail. The route works inside the app container, but Adminer connects from the container's network namespace, so DB_HOST must be the service name (mysql, pgsql) — not 127.0.0.1. If you expose the app on port 80, /adminer is reachable from the host browser without extra port mapping.

Debugging companion to Tinker. Use it for the read-heavy half of debugging: inspect a JSON column, check whether a migration ran, verify a seeder's output. Reach for php artisan tinker when you need model logic; reach for Adminer when you need to see raw rows. Keeping both in muscle memory covers most data-inspection tasks.

Smoke testing the guard. In a feature test, assert that /adminer is reachable in local and 404/403 in production, or that an unauthenticated request redirects. This catches accidental exposure when someone flips the enable flag.

Gotchas and Tips

• Production is disabled by default. The package gates the route on the app environment. If you override this, you own the security. Never enable it with only the default middleware — pair it with auth plus an authorization gate, or an IP allowlist.
• Route changes need a cache clear. Because routes come from the service provider, editing adminer.route in .env without php artisan config:clear (and route:clear if cached) silently leaves you on the old path. A 404 after a config change is almost always this.
• Autologin is best-effort. It fills the form for the connection it understands; unusual drivers, non-default connections, or missing credentials fall back to the manual login screen. Don't treat it as a guaranteed SSO — treat it as convenience.
• Adminer lives outside Laravel's request lifecycle. Its own session handling and form posts don't play nicely with CSRF-protecting global middleware. Use the middleware config key to keep the stack minimal (web with CSRF exclusion, or a dedicated group), rather than letting a broad global stack run over it.
• Sessions can mask credential changes. Adminer persists a login in the PHP session. After rotating DB credentials, a stale session can look like a broken connection — clear cookies or use a private window before debugging the database.
• The bundled Adminer version is whatever the package ships. Old bundled Adminer releases can fail against MySQL 8's caching_sha2_password or newer PostgreSQL auth. If logins fail with auth errors while the app connects fine, check vendor/onecentlin/laravel-adminer for the Adminer version and update the package.
• SQLite expects a filesystem path, not a database name. Point the server field at the absolute path in database.database; relative paths resolve from the web root and fail confusingly.
• Subdirectory and reverse-proxy deployments can break Adminer's asset URLs. If the UI loads unstyled, the route is probably being rewritten — set the route to a simple root-level path.
• Don't commit autologin credentials. Keep DB_PASSWORD in .env; the config should reference the connection config rather than hard-coding values, so config:cache on deploy doesn't bake a password into a committed file.
• Extension point: the config's Adminer path/route knobs are the supported surface. For anything deeper (custom Adminer plugins, login hooks), mount the Adminer single file yourself or subclass the service provider — the package is a thin wrapper, and fighting it is usually slower than copying its route registration.