Open-source dashboard widget API, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

What it is: A lightweight Go API that connects to your self-hosted applications (Vikunja, Linkwarden, and others) and exposes their data as embeddable iFrames you can drop into any dashboard [README].
Who it’s for: Home lab operators and self-hosting enthusiasts who want live data from their apps displayed in Homarr, Homepage, Dashy, or any other dashboard that supports iFrame widgets — without per-app widget coding [README].
Cost: Zero. MIT license, runs in Docker, single binary. Infrastructure cost is zero if you already have a server running [README].
Key strength: Solves a real gap — dashboards like Homarr have iFrame widget slots, but getting your apps’ data to actually show up cleanly requires a serving layer. This is that layer [README][1].
Key weakness: 107 GitHub stars, a single contributor, no built-in authentication, and mixed HTTP/HTTPS can silently break your iFrames. This is a useful but niche utility maintained by one developer in their spare time [README].

What is Homarr iFrames

Homarr iFrames is a Go API server that acts as a bridge between your self-hosted applications and your dashboard. You run it as a container alongside your other services, point it at your Vikunja instance, your Linkwarden collection, your Radarr queue — and it serves live, embeddable HTML snippets via routes like /v1/iframe/linkwarden. Drop that URL into any dashboard’s iFrame widget slot and you get a live view of that app’s data without leaving your dashboard [README].

The name is a bit misleading. Despite being called “Homarr iFrames,” the tool works with any dashboard that can embed iFrames — Homarr, Homepage, Dashy, Heimdall, a plain browser tab, whatever [README]. The “Homarr” in the name reflects where the author originally built it for, not a hard dependency.

The project lives at https://github.com/diogovalentte/homarr-iframes, has 107 stars and 3 forks as of this writing, and has shipped 20 releases. Every commit comes from a single developer, Diogo Valentim. That’s the full picture of the maintenance surface. It runs on Go, ships as a Docker image from GitHub Container Registry (ghcr.io/diogovalentte/homarr-iframes:latest), and exposes a Swagger documentation endpoint at /v1/swagger/index.html [README].

Why people choose it

The self-hosted dashboard space has a specific problem: dashboards are good at linking to apps, but terrible at showing what’s happening inside them. Homarr, one of the more popular options, solves part of this with native integrations for torrent clients, media servers, and a handful of other services [5]. But that list has hard edges. If your app isn’t in Homarr’s integration list, the next best option is an iFrame widget — and for an iFrame to show useful live data rather than a full app UI, you need something to serve compact, themed HTML snippets [1][5].

That’s the gap this project fills. One reviewer described using Homarr’s iFrame widget with a Pomodoro timer as a starting point: “The iframes is a pretty cool feature! I chose this Pomodoro timer… but you could get creative and try out lots of things” [1]. Homarr iFrames industrializes that idea — instead of manually finding embeddable URLs for each service, you get a standardized API that handles the data fetching, theming, and refresh logic.

The XDA Developers comparison of home lab dashboards [2] makes the underlying motivation clear: the whole point of a dashboard is to reduce context-switching. If you have to open Vikunja to check your tasks and Linkwarden to check your reading queue, the dashboard is failing at its job. iFrame embeds are the low-tech path to consolidation when native widget integrations don’t exist [2][5].

The project also surfaces in discussions about Homarr’s built-in iFrame widget [1], which confirms the use case is real: people are actively looking for content to embed that isn’t just arbitrary websites. Structured data from your own self-hosted apps is exactly what they want.

Features: what it actually does

Based on the README and API structure:

Core API:

Each supported source gets its own route: /v1/iframe/linkwarden, /v1/iframe/vikunja, etc. [README]
Query parameters control the number of displayed items, enable auto-update checks (iFrame reloads when source data changes), and customize appearance where supported [README]
Full Swagger documentation at /v1/swagger/index.html — the only way to discover all parameters per source [README]
API runs on port 8080 by default; configurable via PORT environment variable [README]

Source configuration:

Each source requires environment variables: app URL, API token, and any other credentials [README]
Sources are configured at startup via environment variables — no runtime UI for adding sources [README]
A complete list of supported sources is maintained in /docs/SOURCES.md in the repository [README]

Deployment:

Docker image: ghcr.io/diogovalentte/homarr-iframes:latest [README]
Docker Compose support with .env file for credentials [README]
Manual Go build: go mod download && go run main.go [README]
Can run in Docker host network mode for simpler LAN access [README]

What it doesn’t do:

No authentication layer — anyone who can reach the API can pull data from all configured sources [README]
No UI for configuration — environment variables only [README]
No built-in TLS/HTTPS [README]

Pricing: SaaS vs self-hosted math

There is no SaaS version of Homarr iFrames, and no direct commercial equivalent. The tool is MIT-licensed and free to run. The only cost is infrastructure, and since it’s designed to run alongside an existing self-hosted stack, the marginal cost is effectively zero — it adds negligible resource overhead to whatever server already runs your other apps [README].

For comparison: if you wanted live dashboard widgets for Linkwarden and Vikunja without this tool, your options would be to wait for native dashboard integrations (which may never arrive for niche apps), build your own widget API from scratch, or accept a dashboard that just links to your apps without showing data. None of those have a price tag, but the first two have significant time cost.

The actual monetary consideration is setup time. This isn’t a “click deploy” tool — you need to understand Docker environment variables, know your apps’ API tokens, and debug browser console errors when the HTTP/HTTPS mismatch bites you. For a non-technical founder, that’s a few hours minimum, not a few minutes.

Self-hosted infrastructure cost:

If running on an existing home lab server: $0 incremental
If adding a VPS purely for this: doesn’t make sense — it’s too lightweight to justify a dedicated server

Deployment reality check

The README is honest about what can go wrong, which is useful. The main failure modes:

HTTP/HTTPS mismatch. This is the most common trap. If your dashboard runs on HTTPS (as it should if it’s internet-exposed), the iFrame source must also be HTTPS. Modern browsers enforce mixed-content rules and will silently block an HTTP iFrame loaded inside an HTTPS page. The fix is putting Homarr iFrames behind a reverse proxy (Caddy, nginx, Traefik) with a TLS certificate — the same pattern you’d use for any self-hosted service. If you haven’t done this before, budget time to learn it [README].

No authentication. The project explicitly documents that anyone who can reach the API port can retrieve all configured source data. The recommended mitigation is placing an authentication layer in front — Authelia or Authentik are called out by name in the README [README]. This is a real security consideration if you expose the API beyond your LAN. On a home network with the port not forwarded, it’s a non-issue. On a VPS or with Tailscale-style remote access, you need to think about it.

Source-specific environment variables. Every source you want to display requires its own set of environment variables — app URL, API key, sometimes additional config. There’s no UI to add these after the container starts; you edit your .env file and restart the container. If you have 10 sources, you’ll have a dense .env file. The Swagger docs are the only place to discover what each source needs [README].

Single-developer maintenance risk. With 107 stars and one contributor, there’s no bus factor redundancy here. The project has shipped 20 releases and appears actively maintained through late 2025 (the latest release is v1.19.0 - Delete Linkwarden Bookmark button from November 13, 2025), but you’re betting on continued maintenance from one person. For a non-critical dashboard widget layer, that’s acceptable. For production infrastructure, it’s worth noting [README].

Realistic setup time for a technical user: 20–40 minutes to a working iFrame in your dashboard, assuming you have Docker Compose experience and your API tokens ready. For someone new to Docker: 2–3 hours, including reverse proxy setup.

Pros and cons

Pros

MIT license, genuinely free. No commercial tier, no feature gating, no “community edition” limitations [README].
Works with any dashboard. Despite the Homarr name, the output is plain iFrames — embed them in Homepage, Dashy, Heimdall, or anything else with an iFrame slot [README].
Auto-update support. iFrames can be configured to poll for changes and reload when source data updates — you get live data without writing any JavaScript [README].
Swagger docs included. Every parameter for every source is documented via the built-in Swagger UI, which is more thoughtful than most side projects this size [README].
20 releases, active maintenance. The project has shipped consistently and the latest release was in November 2025 [README].
Go binary — lightweight. Minimal resource footprint, runs comfortably alongside other containers on low-power hardware [README].
Fills a real gap. Dashboard iFrame widgets exist specifically for this use case; structured data from self-hosted apps is exactly what they’re designed to display [1][5].

Cons

107 stars, single contributor. If Diogo stops maintaining this, there’s no community to pick it up. For a utility this niche, that’s a realistic risk [README].
No built-in authentication. The README documents this plainly. If your API is reachable without authentication, all your configured source data is readable by anyone on the same network — or the internet, if exposed [README].
HTTP/HTTPS mismatch will silently break things. This is not a bug, it’s a browser security feature, but it catches newcomers who haven’t set up reverse proxies before [README].
Environment-variable-only configuration. No UI to add or remove sources — every change requires editing .env and restarting the container. Manageable, but friction-heavy compared to modern self-hosted tools [README].
Source coverage is undocumented in these materials. The supported sources list lives in /docs/SOURCES.md on the repository but wasn’t available in the provided data. The README only names Vikunja and Linkwarden as examples. Until you check that file, you don’t know if your specific apps are supported [README].
No mobile-friendly mention. The parent Homarr dashboard has documented mobile issues [1], and iFrame widgets on small screens are universally awkward — this utility doesn’t change that.
Not a polished product. This is a well-made side project, not a backed startup with a roadmap. Expectations should be calibrated accordingly.

Who should use this / who shouldn’t

Use Homarr iFrames if:

You already have a self-hosted dashboard with an iFrame widget slot (Homarr, Homepage, Dashy) and want live data from your other apps displayed there.
You specifically run apps that are listed in the project’s SOURCES.md — Vikunja and Linkwarden are confirmed; check the file for the complete list before committing.
You’re comfortable with Docker environment variables and have either set up a reverse proxy before or are willing to learn.
You’re deploying on a home LAN where exposing an unauthenticated API is acceptable, or you already use Authelia/Authentik.

Skip it if:

Your dashboard already has native widget integrations for the apps you care about. Homarr’s built-in integrations cover torrent clients, media servers, and other popular services [5] — check that list first.
You need authentication built in and aren’t prepared to add an auth proxy layer. The no-auth design isn’t a bug that will be fixed; it’s an intentional architecture decision [README].
You’re not technical and have never touched a Docker .env file. The setup requires comfort with environment variable configuration and basic networking concepts.
You’re evaluating this for anything resembling production or business infrastructure. A 107-star, single-developer project is a fine home lab tool, not a reliability anchor.

Pick something else if:

Your goal is a better dashboard overall, not just iFrame content. Homepage [2] and Homarr [1][5] both have richer native widget ecosystems worth evaluating before adding another container to your stack.

Alternatives worth considering

Homarr (the dashboard itself) — Has native integrations for torrent clients (qBittorrent, Transmission, Deluge), media servers, and about 15 services, plus a built-in iFrame widget [5]. If your apps are in that list, you don’t need homarr-iframes. Worth checking before adding the extra container.

Homepage — Frequently cited as the most powerful home lab dashboard [2]. Has an extensive widget library covering both popular and obscure services. Steeper YAML learning curve but more integration depth than Homarr [2][5].

Dashy — Another full-featured dashboard with widget support. Mentioned alongside Homarr as a top Heimdall alternative [5].

Custom iFrame URLs from apps directly — Some self-hosted apps expose embeddable views natively. Notion-style embed URLs, Grafana panels, and similar approaches skip the middleware entirely. Check whether your specific app supports this before deploying another container.

Glance — A newer self-hosted dashboard focused on information density, with its own widget system. Not as established but worth evaluating if you’re starting fresh.

The realistic question for most home lab operators is: does my specific app appear in Homarr iFrames’ supported sources list? If yes, it’s worth trying. If not, you’d be adding infrastructure overhead for zero benefit.

Bottom line

Homarr iFrames solves a specific problem cleanly: if you have a dashboard with an iFrame slot and a self-hosted app with data you want displayed there, this project provides the serving layer you’d otherwise have to build yourself. It’s well-documented for its size, actively maintained, and MIT-licensed. The trade-offs are what you’d expect from a 107-star side project — single point of maintenance risk, no authentication baked in, and a source catalog you can’t evaluate without reading the repository directly.

For a home lab operator already running Docker and comfortable with a .env file, the setup cost is low and the payoff is real. For a non-technical founder looking to centralize their self-hosted stack’s data, the friction is nontrivial — you’d need either the skills or someone to set it up for you. If you fall into that second group and want the self-hosted dashboard experience without the configuration overhead, upready.dev handles exactly that kind of deployment as a one-time service.

Sources

nenrikido.neocities.org — “Homarr and Other Self-hosted Dashboards” (January 20, 2025). https://nenrikido.neocities.org/blog/post/homarr/
Ayush Pande, XDA Developers — “4 reasons Homepage is the best dashboard you should host on your home lab” (March 28, 2025). https://www.xda-developers.com/homepage-is-the-best-dashboard-for-your-home-lab/
rigorousthemes.com — “17 Best Heimdall Alternatives – Self Hosted Personal Dashboard”. https://rigorousthemes.com/blog/best-heimdall-alternatives-self-hosted-personal-dashboard/

Primary sources: