Hi everyone.

I’ve been working on a Phoenix LiveView library that lets you enable/disable routes in real time from a protected dashboard — no redeploy needed. Route discovery happens automatically from your router, and disabled routes return 403 at the Plug level before they ever reach your controller.

What it does:

• Automatically discovers routes from Phoenix.Router.routes/0

• One-click toggle, individual or bulk, live via LiveView

• Blocks disabled routes with 403 via a route guard plug

• Provides session-based login with admin/viewer roles

• Audit log (who did what, when), with CSV export

• Includes search, dark mode, and protected/immutable route(s) config

• Dead render fallback — works even for API-only apps without LiveView JS

Why I built this:
I work on a small team. We had a business requirement to expose some endpoints publicly. Nothing bad happened — no security incident, no hack — but the thought stuck with me: these endpoints are out there, and if something ever goes wrong, what’s the quickest way to limit the blast radius?

That question grew into this idea. The first step isn’t a perfect fix — it’s to turn it off, limit exposure, and buy time to think, hotfix, or deploy a permanent solution. I asked AI to help me explore and assess the use cases, and what started as a small concern grew into something I thought might be valuable beyond just my team.

The honest part about the package:
This is my first Hex package. I’m new to open source. I’m posting this to get your genuine feedback on whether this idea has legs:

• Is this actually useful for teams, or is it solving a problem that’s better handled differently?

• Would you use something like this? If not, why not?

• What’s missing? What’s over-engineered?

A couple of honest caveats:

• Without LiveView JS loaded (e.g. --no-assets apps), it falls back to a dead-render mode — most features still work, but a few JS-dependent ones (bulk checkboxes) are hidden in that mode.

• Storage is currently CubDB only (single-node). PostgreSQL support is something I’m considering adding — thoughts welcome on whether that’d actually be useful to you.

Also: The free-tier route selection UI (the 50-route cap) still needs some work, and I have features like scheduled toggles and PostgreSQL storage in mind. If you spot bugs or design issues, please let me know — I’ll fix them.

Try it out

# mix.exs
{:api_management_console, "~> 0.1"}

Then use ApiManagementConsoleV2.Router in your router and mount it with api_console “/admin/api-console”.

I’d genuinely love to hear:

• Your first impressions

• What would make this a “must-have” for your team

• What I should prioritize next

This is a work in progress, and I’m here to improve it based on real-world needs.

Thanks for reading — and if you try it, let me know how it goes!