The Problem: My Bookmarks Were Useless Across Machines
The thing that finally broke me wasn’t losing bookmarks — it was re-creating the same set of 40 links for the third time in a month. New client engagement, new VPN, new staging environment. Different URLs for the same tools I use every day. I’d pull up the old bookmark folder, manually edit each staging URL one by one, and inevitably miss two or three that still pointed at the previous client’s environment. You don’t notice until you’re halfway through a debugging session wondering why the logs look completely wrong.
Browser sync sounds like it solves this. It doesn’t. Chrome sync works fine if you live entirely in Chrome across every machine. But my work laptop runs Firefox on a corporate profile that’s locked down, my home machine has three Chrome profiles plus a Brave window I refuse to close, and my servers obviously have no browser at all. The bookmarks that matter most — internal dashboards, monitoring URLs, deployment pipelines — live in browser profiles that never talk to each other. Firefox’s sync and Chrome’s sync are parallel universes.
The deeper problem is structural: bookmarks are GUI state, and GUI state doesn’t belong in a workflow that involves multiple machines, multiple environments, and multiple clients. Every time I spin up a new environment I need a different version of the same bookmark set. Staging for Client A is https://staging-a.internal/dashboard. Staging for Client B is https://app-staging.clientb.com/admin. There’s no sensible way to manage that as nested bookmark folders. You end up with folders like “Client B – CURRENT” and “Client B – OLD” and a vague sense of dread.
What I actually wanted was something I could drive from environment variables or a config file — something where I could write STAGING_URL=https://staging-a.internal in a .env file, commit the template to the repo, and get a functional bookmarks page without touching a browser. The config lives next to the project. When the URL changes, I change one line. That mental model — bookmarks as config, not as GUI state — is what led me to look at self-contained generators like Mookbars instead of yet another browser extension or sync service.
What Mookbars Actually Is (Without the Marketing Fluff)
A Single HTML File. That’s the Whole Thing.
Mookbars takes your environment variables and spits out one self-contained HTML file with all your bookmarks organized and clickable. No SQLite, no Postgres, no Redis, no Express server humming in the background — just a file you can open with file:/// or drop behind nginx. I genuinely wasn’t expecting to like this approach as much as I do, but after running it for a few weeks I stopped questioning it.
The env var approach is smarter than it first sounds. Your bookmark config isn’t stored in some proprietary YAML schema or a JSON blob that only Mookbars understands — it lives in .env files, docker-compose.yml environment blocks, or whatever secret manager your org already pipes into containers. That means rotating links, adding new services, or handing config off to a teammate requires zero onboarding into a new tool. They already know how env vars work.
# .env example — this is your entire "database"
MOOKBARS_GROUP_1=DevTools
MOOKBARS_LINK_1_1=Grafana|http://grafana.internal:3000
MOOKBARS_LINK_1_2=Kibana|http://kibana.internal:5601
MOOKBARS_GROUP_2=Docs
MOOKBARS_LINK_2_1=Runbooks|https://notion.so/your-team/runbooks
The honest trade-off: you can’t do dynamic content. There’s no “recently visited” tracking, no search indexing across your actual services, no user-specific views. If you need any of that, Mookbars is the wrong tool. But if you’ve ever caught yourself maintaining a half-broken internal wiki page that’s really just a list of links to internal services, Mookbars is the thing you actually wanted.
Where this actually earns its place:
- Local dev dashboards — generate once, open in a pinned browser tab. Every service URL you spin up locally, organized by category, no fiddling with browser bookmark folders.
- Homelab jump pages — stick the HTML file behind Caddy or Traefik on your home network, access it from any device without installing anything.
- Internal team portals behind a reverse proxy — pair it with nginx auth_basic or Authelia and you have a dead-simple intranet landing page that any team member can contribute to via a PR to the env config.
The thing that caught me off guard was how frictionless the deployment story becomes when there’s no backend. Updating your bookmarks page in a Docker-based homelab is literally changing an env var and restarting a container that runs for maybe two seconds before it exits, leaving behind an updated HTML file. Compare that to running a full Node or Python app just to render a list of links — the operational overhead isn’t worth it for something this simple.
Installation: What the README Says vs What You Actually Do
The README gives you a clean four-step install story. Reality has a couple of extra steps tucked between the lines. Here’s what I actually had to do to get Mookbars serving a working bookmarks page.
What You Get After Cloning
Clone the repo and you’ll land in a structure that’s straightforward once you know what to look at:
mookbars/
├── Dockerfile
├── entrypoint.sh # this is where env vars get parsed into HTML
├── package.json
├── src/
│ ├── index.html # the template
│ └── style.css
└── .env.example # read this before you do anything else
The entrypoint.sh is the interesting file. It’s a shell script that loops over your environment variables, filters the ones prefixed with MOOKBARS_, and injects them into the HTML template at container startup. No database, no config file, no build step — just env vars to HTML. That’s the whole thing, and honestly it’s elegant.
Docker: The Command That Actually Works
The README shows a simplified docker run snippet. This is the version I got to work without additional debugging:
# Run it — maps container port 80 to your local 8080
docker run \
-e MOOKBARS_TITLE='My Dashboard' \
-e MOOKBARS_LINK_GITHUB='https://github.com' \
-e MOOKBARS_LINK_DOCS='https://docs.example.com' \
-p 8080:80 \
mookbars
# Then hit http://localhost:8080 — you should see your page immediately
If you’re using Docker Compose (which you should be, if you have more than five links), define your vars in a .env file and reference it with env_file. Passing twenty -e flags on the command line gets old fast and is a nightmare to diff in git.
Running Without Docker
You need Node 18+ for this. I ran it on Node 20 LTS without issues; Node 16 threw an error on one of the template parsing steps. After cloning:
npm install
npm start
# Or if you want to watch for env changes without restarting:
node src/server.js
The thing that tripped me up here: if you’re loading vars from a .env file locally, Mookbars doesn’t auto-load it. You need to either source it manually or use something like dotenv-cli:
# Option 1: source before running
set -a && source .env && set +a && npm start
# Option 2: dotenv-cli (npm install -g dotenv-cli)
dotenv npm start
The Naming Convention Gotcha That Will Eat Your Afternoon
This is the one the README buries or skips entirely. Environment variable names must be all caps, use underscores only (no dashes), and follow the exact prefix format. If you write MOOKBARS_my-link or mookbars_link in lowercase, the parser silently skips it. No error, no warning — your bookmark just doesn’t appear. The correct pattern:
# ✅ Works
MOOKBARS_LINK_GITHUB=https://github.com
MOOKBARS_LINK_INTERNAL_WIKI=https://wiki.internal.net
# ❌ Silently ignored — dashes in the key name
MOOKBARS_LINK_MY-TOOL=https://example.com
# ❌ Silently ignored — lowercase prefix
mookbars_link_github=https://github.com
The reason this burns people is that shell .env files often tolerate mixed conventions, so you copy-paste a variable name with a dash from somewhere else and nothing breaks — the entry just never renders. Add a grep -i 'mookbars' check on your env before debugging the HTML output. Nine times out of ten the variable name is the problem.
Configuring Your Bookmarks via Environment Variables
The naming convention clicked for me immediately once I stopped reading the docs and just looked at the variable names. MOOKBARS_GROUP_1 is your group label — the heading you see rendered on the page. Then MOOKBARS_GROUP_1_LINK_1_NAME and MOOKBARS_GROUP_1_LINK_1_URL are the first bookmark under it. Want a second link in that group? MOOKBARS_GROUP_1_LINK_2_NAME and MOOKBARS_GROUP_1_LINK_2_URL. New group entirely? MOOKBARS_GROUP_2. The indices are what drive the hierarchy — group number scopes everything under it, link number sequences within that group. No JSON, no YAML, just flat numbered env vars that map directly to what you see rendered.
Here’s a real .env structure I use organized by team function, which is more durable than organizing by environment (prod/staging/local tend to have the same links anyway, just different hostnames):
# ── DevOps ──────────────────────────────────────────
MOOKBARS_GROUP_1=DevOps
MOOKBARS_GROUP_1_LINK_1_NAME=Grafana (Prod)
MOOKBARS_GROUP_1_LINK_1_URL=https://grafana.internal.example.com
MOOKBARS_GROUP_1_LINK_2_NAME=ArgoCD
MOOKBARS_GROUP_1_LINK_2_URL=https://argocd.internal.example.com
MOOKBARS_GROUP_1_LINK_3_NAME=Vault
MOOKBARS_GROUP_1_LINK_3_URL=https://vault.internal.example.com
# ── Frontend ─────────────────────────────────────────
MOOKBARS_GROUP_2=Frontend
MOOKBARS_GROUP_2_LINK_1_NAME=Storybook (Staging)
MOOKBARS_GROUP_2_LINK_1_URL=https://storybook.staging.example.com
MOOKBARS_GROUP_2_LINK_2_NAME=Figma
MOOKBARS_GROUP_2_LINK_2_URL=https://figma.com/file/YOURFILEID
# ── Monitoring ───────────────────────────────────────
MOOKBARS_GROUP_3=Monitoring
MOOKBARS_GROUP_3_LINK_1_NAME=Sentry
MOOKBARS_GROUP_3_LINK_1_URL=https://sentry.io/organizations/your-org
MOOKBARS_GROUP_3_LINK_2_NAME=PagerDuty
MOOKBARS_GROUP_3_LINK_2_URL=https://your-org.pagerduty.com
The comments above each block are load-bearing for your own sanity. They’re stripped out before the variables ever reach the process, but they keep a 40-line .env from becoming a wall of uppercase noise. The shell comment trick (# prefix) works in Docker Compose’s env_file loading too, so use it liberally.
Dropping this into Docker Compose is straightforward. The critical thing is to never paste credentials or internal hostnames directly into docker-compose.yml if that file is committed to git. Use env_file instead, and keep the actual .env in .gitignore. Commit a .env.example with placeholder values so new team members know the shape without exposing real URLs:
services:
mookbars:
image: mookbars:latest
ports:
- "3000:3000"
env_file:
- .env # real values, gitignored
# don't put MOOKBARS_GROUP_* inline here — that defeats the purpose
The gotcha nobody warns you about: once you cross roughly 60 bookmarks — around 20 groups with 3 links each — the config stops being readable as a human document. The gap between MOOKBARS_GROUP_7_LINK_4_URL and understanding which team or service that represents in your head is too large. Two strategies that actually help: strict ordering discipline (alphabetical within a group, or frequency-of-use descending) and keeping every group to 5 links maximum. If a group is growing past 5, that’s a signal to split it. A “Backend” group with 11 links should become “Backend – Services” and “Backend – Databases”. The config stays flat either way, but your mental model stays clean.
One more thing that bit me: gaps in the index sequence silently break parsing. If you define LINK_1 and LINK_3 but forget LINK_2, depending on how Mookbars iterates, you may only get the first link rendered. Always keep your sequences contiguous. If you delete a bookmark, renumber everything after it — tedious, but a find-and-replace in your editor takes ten seconds.
The Three Things That Actually Surprised Me
I went into Mookbars expecting a basic link-dump tool. What I got was something that actually fits into real infrastructure patterns without bending over backwards to make it work.
The generated HTML has zero external dependencies
I ran it expecting to see a Google Fonts import or a CDN-loaded CSS framework somewhere in the output. There’s nothing. The entire page — styles, structure, everything — is baked into a single HTML file that functions identically offline. That’s not a small thing if you’re operating in an air-gapped environment (think corporate security zones, government networks, or a dev laptop on a plane). Most “simple” bookmark tools still phone home for a favicon API or pull a stylesheet from unpkg. Mookbars doesn’t. I verified this by running the output through a network proxy with external traffic blocked — the page loaded without a single failed request.
The nginx setup is genuinely five minutes
You generate the file once, drop it somewhere nginx can serve it, and write one location block. The whole team now has a shared jump page at an internal subdomain. Here’s the actual config:
server {
listen 80;
server_name jump.internal.yourcompany.com;
location / {
root /var/www/mookbars;
index bookmarks.html;
# disable caching so regenerated files appear immediately
add_header Cache-Control "no-store";
}
}Reload nginx, regenerate the HTML file via a cron job or a CI pipeline step, and you’re done. No Node process to keep alive, no database, no reverse-proxy WebSocket headaches. The thing that caught me off guard was how much this model — static file, simple server, regenerate on demand — outperforms running yet another internal web service when all you need is a list of links.
Env var–driven bookmarks unlock real secrets management
This is the one that made me stop and think. Because Mookbars reads bookmarks from environment variables, you can point it at Kubernetes secrets or AWS SSM Parameter Store with no extra glue code. Your internal tool URLs — the ones that rotate when you redeploy services or change load balancer rules — can update the bookmark page automatically without anyone opening a text file.
# Example: pulling SSM params as env vars before generating
export MOOKBAR_GRAFANA=$(aws ssm get-parameter \
--name /prod/tools/grafana_url \
--query Parameter.Value \
--output text)
export MOOKBAR_ARGOCD=$(aws ssm get-parameter \
--name /prod/tools/argocd_url \
--query Parameter.Value \
--output text)
# Now generate — the HTML reflects current infrastructure URLs
mookbars generate > /var/www/mookbars/bookmarks.htmlRun that in a scheduled Lambda or a Kubernetes CronJob and your jump page is always current. The alternative — a wiki page or a manually maintained HTML file — drifts within weeks. Someone updates the Grafana endpoint, forgets to update the bookmark page, and then three people ping you asking why the link is broken. The env var model eliminates that entire failure mode by making the source of truth the same place you already manage secrets.
Real Deployment Patterns I’ve Actually Used
The trailing slash in nginx’s proxy_pass directive nearly ruined my afternoon. I had Mookbars running perfectly on port 8080, spun up nginx in front of it, and got nothing but 404s. The fix was one character. I’ll show you that config in a minute, but first — the three patterns I actually run.
Pattern 1 — Local Dev Homepage
This is the one I set up first and still use daily. A .env file in the project root, docker compose up -d, then set localhost:8080 as your browser’s new tab page. That’s genuinely it. The .env file is just your bookmarks as environment variables:
# .env
BOOKMARK_GITHUB=https://github.com
BOOKMARK_JIRA=https://mycompany.atlassian.net
BOOKMARK_STAGING=https://staging.myapp.com
BOOKMARK_DOCS=https://docs.myapp.com/internal
# docker-compose.yml
services:
mookbars:
image: mookbars:latest
env_file: .env
ports:
- "8080:8080"
restart: unless-stopped
The restart: unless-stopped matters here — you want this surviving reboots without thinking about it. Editing bookmarks is just vim .env followed by docker compose restart, which takes about two seconds. Compare that to syncing browser bookmarks across machines or maintaining a shared Notion page nobody updates.
Pattern 2 — Shared Team Dashboard
We ran this on a $6/month Hetzner VM that was already hosting a few internal tools. The setup is the same docker-compose as above, except you add nginx in front and set up an internal DNS record pointing bookmarks.internal at the VM’s LAN IP. Anyone on the office VPN hits a clean URL with real links to every environment, runbook, and admin panel. No more “what’s the URL for the staging Grafana again?” in Slack.
# /etc/nginx/sites-available/bookmarks.internal
server {
listen 80;
server_name bookmarks.internal;
location / {
proxy_pass http://127.0.0.1:8080/; # trailing slash is not optional
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
The team DNS entry is just an A record in your internal resolver (Pi-hole, pfSense, whatever you run) pointing to the VM’s private IP. No SSL needed for a purely internal tool unless your security policy demands it — though adding a self-signed cert with nginx is worth doing if engineers are going to leave this tab open all day.
Pattern 3 — Per-Environment Jump Pages in CI/CD
This one took the most setup but pays back quickly on projects with dev/staging/prod environments that each have their own cluster of URLs. The CI pipeline generates a different .env per environment and deploys a separate Mookbars instance for each. Engineers bookmark jump.dev.myapp.com, jump.staging.myapp.com, etc., and each one shows only the URLs relevant to that environment. No accidentally clicking the prod database console from the dev jump page.
# .github/workflows/deploy-bookmarks.yml (excerpt)
- name: Generate env file for ${{ matrix.env }}
run: |
cat > .env.${{ matrix.env }} <The nginx Gotcha That Cost Me 20 Minutes
If you write proxy_pass http://127.0.0.1:8080 without the trailing slash, nginx appends the full request URI to the upstream URL. So a request to /favicon.ico becomes http://127.0.0.1:8080/favicon.ico — fine. But requests to the root become http://127.0.0.1:8080 with no path normalization, and depending on how Mookbars routes internally, you either get a redirect loop or a bare 404. Adding the slash — proxy_pass http://127.0.0.1:8080/ — tells nginx to strip the location prefix before forwarding. One character, totally non-obvious from the error output, documented in the nginx docs under a section most people skip.
Honest Limitations You Should Know Before Committing
The thing that will bite you fastest is the absence of search. Fifty bookmarks feels manageable until you're demoing this to a teammate at 2pm and you can't remember which group you put that staging API endpoint in. There's no fuzzy filter, no keyboard shortcut to jump to a group, nothing. You scroll. If your bookmark count stays under 30 and your groups are well-named, this is fine. Past 50, it becomes a real daily friction point.
Favicons are absent by default. The output is clean in a brutalist way — text, links, groups — but it reads more like a generated config dump than a tool people will reach for habitually. Team adoption lives or dies on whether something feels nice to use, and a wall of unstyled links doesn't clear that bar for most non-engineering teammates. You can work around this by adding custom CSS if the generator exposes a styling hook, but that's extra work you probably didn't budget for.
The deployment-as-edit-cycle is the sharpest limitation for mixed teams. The workflow is:
- Open your
.envfile or CI secret store - Add or change a
MOOKBAR_GROUP_NAME_URLentry - Trigger a redeploy
- Wait for the build pipeline
For a solo dev or a small infra team that's already doing this dance daily, the overhead is negligible. For a product manager who wants to add a Figma link on a Tuesday afternoon, it's a blocker. They'll Slack you, you'll forget, and the bookmark page will drift from reality within a month.
The env var format itself starts to break down around the 50-bookmark mark. You end up with something like this in your shell or CI config:
# This is what 40+ bookmarks actually looks like
MOOKBAR_INFRA_GRAFANA=https://grafana.internal.example.com
MOOKBAR_INFRA_PROMETHEUS=https://prometheus.internal.example.com
MOOKBAR_INFRA_ALERTMANAGER=https://alerts.internal.example.com
MOOKBAR_STAGING_API=https://api.staging.example.com
MOOKBAR_STAGING_ADMIN=https://admin.staging.example.com
# ...30 more lines of thisAt that scale you start wishing the tool accepted a single bookmarks.yaml or bookmarks.toml file instead. Flat env vars have no hierarchy, no comments that survive tooling, and diffing changes in a PR becomes genuinely painful. YAML would let you add metadata per link, group descriptions, ordering hints — none of which you can express cleanly in an env key name.
Mookbars is not a Raindrop.io replacement and shouldn't be evaluated like one. If your team needs shared collections, per-link tagging, mobile access, browser extension sync, or any kind of collaborative curation — pick a real bookmark manager. Where Mookbars wins is the narrow case of a self-hosted, version-controlled, infra-adjacent link page that lives inside your deployment pipeline. Step outside that use case and you'll spend more time fighting limitations than the tool saves you.
When Mookbars Is the Right Call (and When It Isn't)
The thing that makes Mookbars genuinely useful is also what limits it: it does exactly one thing. It reads env vars and spits out a static bookmarks page. No daemon running, no state to corrupt, no midnight pager alerts because the database ran out of connections. If your use case fits that shape, it's a near-perfect tool. If it doesn't, you'll be fighting it from day one.
Where Mookbars genuinely shines
Homelab dashboards are the obvious sweet spot. You've already got a .env file or a Docker Compose config with half your infrastructure URLs in it — Mookbars just turns that existing config into something clickable. Same logic applies to per-environment developer jump pages. I've seen setups where staging, prod, and local dev each get their own container instance, each fed a different env block, so every environment has a jump page that only shows the services that actually exist in that environment. No stale links to prod Grafana showing up in your local dev tab.
Air-gapped networks are where Mookbars really earns its keep. When you can't pull from the internet, a tool with zero runtime dependencies and no external auth provider is a genuine relief. You bake the image, ship it in, run it. That's the whole story. The same principle applies anywhere you're already managing config through env vars — Kubernetes ConfigMaps, Nomad job specs, Ansible-templated .env files. The bookmarks page becomes a natural output of infrastructure you're already maintaining rather than a separate thing someone has to remember to update.
# docker-compose.yml fragment — this is the entire "configuration"
services:
mookbars:
image: mookbars:latest
environment:
- BOOKMARK_1_LABEL=Grafana
- BOOKMARK_1_URL=http://grafana.internal:3000
- BOOKMARK_2_LABEL=Prometheus
- BOOKMARK_2_URL=http://prometheus.internal:9090
ports:
- "8080:8080"
Zero moving parts is a legitimate feature, not just marketing copy. No database means no backup job to forget configuring. No auth layer means no OAuth app credentials to rotate. No upgrade path that involves schema migrations. If the container is running, the page works. If the container isn't running, you start it. That operational simplicity compounds over time — eighteen months from now you won't be debugging why the bookmark service is returning 500s because a dependency released a breaking change.
Where you should look elsewhere
Non-technical teams are a hard no. If someone needs to add a bookmark and the answer is "edit the env vars and redeploy the container," you're going to end up being the person who edits the env vars and redeploys the container. Every time. Tools like Dashy or Heimdall have actual UIs for this exact reason — they trade the operational simplicity for self-service capability. That's a legitimate trade depending on who's using the tool.
Don't reach for Mookbars if you need search, tag filtering, or sync across your personal devices. It's a server-rendered page served to whoever can hit the URL — there's no concept of a user, no personal collections, no browser extension syncing state. For personal bookmark management you want something like Linkding or Raindrop.io. Mookbars is a shared, server-side jump page, not a personal bookmark manager, and conflating those two use cases will leave you disappointed. For a broader look at tools that solve adjacent problems — including dashboard and internal tool options that handle more complex team requirements — the guide on Essential SaaS Tools for Small Business in 2026 is worth a read before you commit to any particular approach.
Quick Comparison: Mookbars vs the Alternatives I Considered
I spent an embarrassing amount of time hand-rolling a static HTML bookmarks page before switching. My version was a single index.html file with hardcoded <a> tags, committed to a private repo, manually SSHed onto whatever machine I was using. It worked until I spun up a new VM and forgot to copy the file, or edited it in one place and had three stale copies floating around. Mookbars solves exactly that problem — the config lives in environment variables, which means it lives in your secrets manager, your .env file tracked in a private repo, or your container orchestrator. The bookmarks go wherever the container goes.
Homer is the serious competitor here. It's YAML-configured, has a healthy community, supports service icons from walkxcode's icon pack, and produces a genuinely nice-looking output. If your first reaction to a bookmarks page is "I want it to look good and I don't mind maintaining a YAML file on a volume mount," Homer is probably what you want. The honest trade-off: Homer's config is a file that lives on a filesystem somewhere. That's fine for a homelab NAS that never moves. It's annoying when you're deploying across multiple environments with different URLs per environment — dev, staging, prod all need different links, and templating a YAML file starts feeling gross fast.
Heimdall requires a database, persists state, and has features like app status pings and an enhanced apps store. That's not overkill — it's a different product. If you want a database-backed dashboard that remembers state between deployments and has a UI for editing, Heimdall is fine. But I don't want a SQLite file I have to back up just to keep my jump page working. The maintenance surface is too wide for what amounts to a list of links.
Organizr isn't really in the same category. It has authentication, tabbed iframes, user management, and integrates with things like Plex and Sonarr. Comparing it to Mookbars is like comparing Nginx to a Python http.server one-liner. Both serve HTTP, but they're solving different problems for different people at different scales. If you're running a shared homelab with multiple users who need different views, Organizr makes sense. For a personal jump page you open in a new tab, it's massive overkill.
The honest verdict: Mookbars wins in one specific situation — when env-var-driven config is a hard requirement. That means Docker Swarm with secrets, Kubernetes with ConfigMaps, Fly.io or Railway where your environment variables are the canonical config store, or any setup where you're allergic to mounting config files. Outside of that constraint, Homer gives you a better-looking result with more community support and I'd recommend it without hesitation. The decision is basically: "Do I want to manage a YAML file or do I want to manage environment variables?" Pick the one that fits how the rest of your infrastructure already works.
