Db Console Webui Laravel Package

Product Decisions This Supports

• Build vs. buy for internal database operations tooling. The package now covers the full operator loop for the two resources teams actually self-serve — databases and accounts — including creation, dropping an account (previously promised in the component docblock but unimplemented), role and webhook management, and a server switcher. That is the scope where an in-house admin panel usually starts costing engineering quarters, so this is the moment to decide whether to adopt rather than staff a build.
• Whether to expose provisioning to teams, or keep it an ops-only tool. The v0.1.1 existing-resource semantics are a product decision, not a technical one: db-console now refuses to silently "create" an account or database that already exists, and instead offers an explicit adopt choice (including adopt-and-rotate-password) with the risk of each stated, only when the refusal actually offers that policy. That gives you a defensible answer to "what happens when a developer types a name that already exists?" before you put this in front of non-ops users.
• Managed-database provider support as a roadmap line. The screens now read where a server runs from db-console's hosting profile: the account host defaults to ServerRegistry::defaultAccountHost() (% on managed MySQL) instead of a hard-coded localhost, the switcher shows the provider, and the wizard routes operators to the provider's point-in-time recovery as the restore path when a backup fails, reporting BackupFailed distinctly. That is the difference between "works in a lab" and "usable against RDS-style managed instances" — treat first-class managed support as shipped and scope the remaining providers explicitly.
• Security/governance posture as a sellable artifact. Assurance refusals now link to the host's own password.confirm route when it exists — the WebUI never authenticates, it points at the host. Combined with the new live CI job that exercises the wizard and account manager against real MySQL 8.4 and PostgreSQL 18 as a restricted admin (db-console's minimal grant with sql_require_primary_key=ON; a non-superuser CREATEDB CREATEROLE role on Postgres), and LiveAdminGrantTest keeping the CI grant equal to MinimalAdminGrant, you can hand a security reviewer a least-privilege story rather than a promise.
• Upgrade-window planning. Route names, Livewire component names, install command, browser event and translation/view namespaces all moved to vendor-scoped laranail-db-console-webui.* forms, with bare names kept working behind a one-time deprecation warning and removal signposted as "no earlier than the next minor after 0.1." This is a schedulable migration, not a surprise break — but it does need a ticket, and your own docs/saved links/routeIs() checks are the exposure.
• Platform-version gating. illuminate/console, illuminate/http and illuminate/routing are now declared at ^13.0. Any roadmap item that assumes this UI runs on your current Laravel version needs checking against that floor before it is committed.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel 13 with Livewire, and are willing to track a 0.x package (pin exact versions; expect churn, but churn that arrives with deprecation warnings and stated removal windows).
• You need a Livewire/Blade admin surface for databases, accounts, roles and webhooks — not a JSON API, not a CLI.
• Your fleet is MySQL 8.x or PostgreSQL and at least partly managed (host scoping, provider display and PITR-as-restore-path are now handled).
• You can grant a restricted-but-real admin role — the package's value depends on actually performing CREATE DATABASE / CREATE USER work. The tested minimal grant is documented and CI-enforced; if your platform team will not grant anything near it, the product collapses to a read-only browser.
• You want explicit, auditable resource semantics — adopt-vs-create with per-policy risk text and "adopted, not created" reporting — rather than a tool that overwrites silently.
• You already use, or are willing to adopt, laranail/db-console ^0.1.1 (hard requirement: existing-resource policy and operator assurance live there) and laranail/package-tools ^0.1.3 (now a direct dependency, not transitive).

Look elsewhere when:

• You are on Laravel 10–12, or on a non-Livewire/API-first architecture.
• You need SQL Server, SQLite, or engines without host scoping as a first-class citizen.
• You require a 1.0 stability guarantee or a long-term-support branch; every removal here is "next minor after 0.1," which is honest but not a stability commitment.
• You cannot grant anything beyond a narrowly-scoped, single-database user — the wizard and account manager are then mostly inert.
• You have an existing in-house console with deep workflow integration; the migration cost of the namespace and route-name changes plus the 0.x cadence likely outweighs the buy.

How to Pitch It (Stakeholders)

To executives: This is the internal database console we would otherwise build. The v0.1.1 release closes the gaps that blocked production use: operators can now drop accounts, not just create them; the UI understands managed databases (correct account hosts, provider visibility, and backup-failure/PITR guidance instead of misleading generic errors); and existing accounts or databases are surfaced as an explicit adopt-or-abort decision with the risk of each choice spelled out, never a silent "success." It also hands security a concrete answer: authentication stays with our host app via password.confirm, and the package's integration tests run against real MySQL 8.4 and PostgreSQL 18 under db-console's documented minimal admin grant, with a test that fails if CI's grant drifts from it. Cost and risk: the package is pre-1.0 and now requires Laravel 13 and laranail/db-console ^0.1.1, so this is a scoped adoption with pinned versions and a scheduled upgrade ticket — not a drop-in.

To engineering: v0.1.1 is a stabilisation release you should take as a unit. It fixes two real defects — published translation overrides were never read (the package translated through the hyphen namespace while vendor:publish wrote to the slash one; it now translates canonically and still honours hyphen overrides, canonical winning), and BareRouteNameResolver could raise a TypeError under strict_types when a previously-installed resolver returned a non-string. It also fixes a test that left published views in the Testbench skeleton vendor/ and shadowed the package's own views on every later local run — which is why changed views "didn't show." Naming is now centralised in Support\RouteNames, LivewireNames, BrowserEvents and Translations, with NamingConventionTest reading the live router, rate limiter, Artisan and middleware registries and failing on any bare name the package owns. Bare route names, the bare install command, the bare Livewire names, the db-console:server-changed event and Routing\BareRouteNameResolver are all deprecated with a one-time warning and a removal floor of "the next minor after 0.1"; bare route() names still resolve, but Route::has() and routeIs() see only scoped names — so grep for those. Dependencies are now declared rather than inherited: illuminate/* at ^13.0, laranail/db-console ^0.1.1, package-tools ^0.1.3. Note the middleware and README now check db-console's scoped abilities (laranail-db-console.database.view, laranail-db-console.server.view); the old db-console.* names still work as deprecated aliases, so existing host policies keep functioning — update them on your own schedule, not in this upgrade.