Your Password Manager Isn’t a Launcher

Every morning I open Keeper, search for “GA4”, copy the URL, paste it into a new tab, and repeat that little dance for Search Console, three localhost ports, and whichever GitHub repo I’m reviewing that day.

Keeper is excellent at the one job it’s built for: keeping my passwords safe. But as a way to launch the twenty-odd things I actually touch every day, it’s painful. No one-click “open my whole workspace”. No tagging by project. No quick visual scan to remind me which of these three localhost ports is the frontend. Just a flat, alphabetical list of secrets.

So I went looking for a better way to organise the links and environments I use daily — and it turns out there isn’t one right answer. There are three, depending on how much setup you’re willing to do.

TL;DR:

• A password manager is a security vault, not a launcher — keep credentials there and nothing else.
• For daily work, use browser tab groups (Chrome saves closed groups for one-click reopening) or a keyboard launcher such as Raycast.
• For a status overview of local and remote services, self-host a dashboard: Homepage or Dashy show live up/down indicators; Linkding is a tag-first bookmark store.
• My setup is two layers: tab groups for daily execution, a small Homepage instance for cross-project audits.

Why a password manager makes a bad developer launcher

Password managers are optimised for security, not speed. Every entry is one flat item behind a master password, sorted alphabetically or by folder at best. There’s no concept of “open these six things together because I’m about to review a deploy”, and no live indicator telling you whether localhost:8000 is even running before you click through to a connection error.

That’s not a flaw — it’s just a different job. Once I accepted that, the question became simpler: what is built for fast, grouped, visual access to the tools and ports I use every day?

Option 1: Self-hosted developer dashboards (Homepage, Dashy, Linkding)

A self-hosted developer dashboard is a small web app you run locally that puts external tools (GA4, GitHub) and local services (localhost:3000) on one page, usually with live status indicators. If you want a single browser tab that’s your command centre, this is the closest thing to the “cockpit” I was after.

Homepage is the one I’d start with. You configure it in plain YAML (services.yaml), grouping apps into sections such as Analytics, Dev Workspaces, or Staging. Its standout feature is live status: each service can show a green or red dot, so you know whether that Docker container is actually up before you click through to “connection refused”.

Elena's Command Centre with Homepage, September 2026

One gotcha I’d have liked to know earlier: Homepage offers two status checks, and they’re not interchangeable. According to the Homepage services docs, siteMonitor sends an HTTP HEAD request to the URL (falling back to GET) and reports the response time. The older ping option is an ICMP ping of the host — it ignores the port, so a ping on localhost stays green even when the dev server on port 3000 has crashed. For local ports, use siteMonitor:

# services.yaml
- Local Dev:
    - Frontend:
        href: http://localhost:3000          # opened by your browser
        siteMonitor: http://host.docker.internal:3000  # checked by the Homepage container
        description: React dev server

The two URLs differ because the check runs inside the Homepage container, where localhost means the container itself. On Docker Desktop, host.docker.internal points back at your machine.

Dashy covers similar ground with a visual UI editor, themes, and keyboard shortcuts, if you’d rather not hand-write YAML. Status checks are opt-in: set appConfig.statusCheck: true in conf.yml and Dashy shows a status dot next to each item, with an optional statusCheckInterval for continuous polling.

Linkding is a different shape of tool: a minimal, fast, tag-first bookmark manager designed to be set up with Docker, storing bookmarks in SQLite by default. Linkding is less “dashboard”, more “searchable filing cabinet” — tag entries #project-a, #local, #analytics, then find them by keyboard in seconds. It also ships Firefox and Chrome extensions for saving links as you go.

Homepage, Dashy, and Linkding all run happily from one docker compose up, which is the only real setup cost.

Option 2: Browser tab groups and bookmark managers (no deployment)

If spinning up another local service feels like solving one chore by creating another, you can get most of the same benefit without leaving your browser.

Tab groups and workspaces (Chrome’s Tab Groups, Spaces in Arc, or tab groups and profiles in Brave) let you build a named, collapsible bundle per project — say [Local Dev] with your three ports, and [Analytics] with GA4 and Search Console. In Chrome, closing a group doesn’t delete it: the group is saved and syncs across devices signed in to the same Google Account, and you reopen the whole set from the bookmarks bar or the Tab Groups menu. Pinned tabs handle the things you want open permanently, like production or your PR dashboard.

Raindrop.io is the cloud-based upgrade to plain bookmarks: nested collections, tag filters (#dev, #prod, #console), and visual preview cards, synced across every browser you use.

Browser-native organisation needs zero infrastructure and is genuinely instant to set up — which matters if, like me, you’ll abandon anything that takes longer than an afternoon.

Option 3: Raycast Quicklinks and OS-level launchers (keyboard-first)

If clicking bookmarks at all feels slow, move the whole thing to your keyboard. On macOS, Raycast has Quicklinks: named shortcuts that open a URL, a folder, or a search, which you can tag by project and bind to a hotkey. A useful detail for dev work is Prefer Existing Tabs — if the page is already open in Chrome or Safari, Raycast switches to that tab instead of opening a duplicate.

A single Quicklink opens a single URL, though. To open a whole working set at once — localhost:3000, your GA4 property, and your GitHub PR list — add an extension such as Multilinks from the Raycast Store, or write a small script command. A port-manager extension will also show you what’s currently listening on your local ports, so you can jump straight to the right one. Flow Launcher does the equivalent on Windows.

Raycast is the fastest workflow of the three, but it’s also the one with the steepest habit-forming cost: a launcher only pays off once “review project-a” is muscle memory.

Comparison: dashboards vs tab groups vs launchers for developer links

Two-layer system: tab groups for daily work, Homepage for audits

I didn’t pick one of these and call it done. I ended up running two layers, because they solve different problems.

Layer one — daily execution. Browser tab groups (or Raycast, if you’re that way inclined) bundle each project’s working set: local frontend and backend ports, the GA4 property, the Search Console property, and the repo’s PR list. I open these first thing, every day, without thinking.

Layer two — review and cataloguing. A lightweight Homepage instance, split into Local Services (ports, admin UIs, local databases), Monitoring (deep links straight into each project’s GA4/GSC profile), and Staging/Production. I only open the dashboard when I’m auditing something across every project at once — which is rare enough that it doesn’t need to be instant, just organised.

Mental model: password manager vs launcher vs dashboard

Think of it like a workshop. Your password manager is the locked safe in the corner — exactly where your valuables should live, and exactly the wrong place to keep the tools you reach for fifty times a day. Tab groups and Raycast are the pegboard above your workbench: the hammer and screwdriver you use constantly, hung where your hand already expects them. The dashboard is the labelled cabinet against the wall — everything catalogued, nothing urgent, useful when you need to find something you don’t reach for daily.

Three different places, three different retrieval speeds. Trying to make one of them do all three jobs is what sent me looking for this in the first place.

Checklist for organising developer links and local environments

1. Keep secrets in your password manager. Don’t put credentials in a dashboard or bookmark tool.
2. Pick one daily-execution layer — tab groups or a keyboard launcher — and build your project bundles there first.
3. Only add a self-hosted dashboard if you genuinely review multiple projects’ status side by side; otherwise it’s a maintenance cost for a feature you won’t use.
4. If you do run Homepage, monitor local ports with siteMonitor, not ping.
5. Tag consistently from day one (#project-a, #local, #prod) — an untagged link pile is just Keeper with extra steps.
6. Revisit the setup after a couple of weeks. If you’re still pasting URLs from memory, the bundles aren’t covering the right things yet.

Final thoughts on organising developer links

None of this needed to be complicated, and that was rather the point. I’m not looking to run a homelab-grade command centre for six local ports — I’m looking to stop retyping localhost:8000 from memory every morning. Tab groups plus a five-minute Homepage setup got me there. Your mix might land differently, and that’s fine: the only wrong answer is asking your password manager to do a launcher’s job.

If you’re also tidying up your local dev environment, I’ve written before about using access tokens safely with GitHub — worth pairing with whichever setup you land on here, since a launcher is only as safe as what you don’t put in it.

References

• Homepage — self-hosted dashboard with live service status
• Homepage: Services configuration (siteMonitor, ping)
• Dashy — configurable dashboard with UI editor and status monitoring
• Dashy: Configuring (statusCheck, statusCheckInterval)
• Linkding — minimal, tag-first, Docker-based bookmark manager
• Google Chrome Help: Manage tabs and tab groups
• Raindrop.io — cloud bookmark manager with tags and collections
• Raycast — macOS launcher
• Raycast Manual: Quicklinks
• Raycast Store: Multilinks — open multiple links at once