Self-hosted homepages, honestly reviewed. No marketing fluff, just what you get when you run it on your own server.

TL;DR

What it is: A lightweight Go web application that serves as a self-hosted startpage — a visual collection of links and small custom pages, configured through a single YAML file [README].
Who it’s for: Homelab runners, sysadmins, and privacy-conscious users who want a custom browser homepage with their own service links, without running anything heavier than a small Docker container [README].
Cost: $0 software + ~$5/mo VPS if you want it on a server, or zero if you run it locally on your homelab machine [README].
Key strength: Genuinely minimal — a single config.yml controls everything. The Docker image is small, the Go binary is statically compiled, and setup is measured in minutes, not hours [README].
Key weakness: 100 GitHub stars and no independent third-party reviews found. This is a small, solo-developer project. It works for what it does, but it doesn’t compete on features with Homarr or Dasherr for users who want service health checks, widgets, or integrations [README][GitHub].

What is portkey

portkey (lowercase, by developer CodeHat) is a Go-based web portal you self-host as a startpage. Point your browser’s new-tab page at it and you get a clean grid of links, a search box with keyword shortcuts, optional dark/light mode, and the ability to add small custom HTML/Markdown pages. The entire thing is configured in a single config.yml — no database, no admin UI, no separate API — and it reloads on change [README].

The name comes from Harry Potter. The GitHub description is straightforward: “A simple web portal that can act as startup page and shows a collection of links/urls. It also supports adding small custom pages.” That’s the product. No stretching.

The project is built on Go, uses Tailwind CSS for styling, ships as a tiny Docker image (codehat/portkey on Docker Hub), and has a live demo at https://demo.portkey.page where you can see the interface before committing to anything [README]. As of this review: 100 GitHub stars, 3 forks, 539 commits, AGPL-3.0 license, maintained by a single developer at CodeHat.

This is not to be confused with Portkey.ai — a separate, unrelated enterprise LLM gateway product. Same name, completely different domain.

Why people choose it

There are no independent reviewer articles for portkey at this star count. What the README and config documentation reveal is a deliberate philosophy: one config file, nothing else.

Most startpage tools eventually add a database, a GUI for editing links, user accounts, plugin systems, and before long you’re running a small CMS just to manage your bookmarks. portkey doesn’t. The config is the source of truth. If you want to add a link, you edit config.yml. If you want to change the title, you edit config.yml. You can even overwrite any config key via environment variables prefixed with PORTKEY_ — so it plays cleanly with Docker Compose secrets and env files [README].

The search box is the other differentiator. You can configure keyword shortcuts so that typing gh routes you to GitHub, dc to your Datadog dashboard, or srv to your server list. This turns the startpage into a lightweight command launcher without any browser extension required [README].

The custom pages feature lets you embed small informational pages — a cheat sheet, a runbook snippet, a contact list — all still driven by the same config file [README].

Features

Based on the README and configuration documentation:

Core link portal:

Grid of links configurable in YAML — groups, labels, icons, URLs [README]
Search box with configurable keyword shortcuts for fast navigation [README]
Dark and light mode (user-toggleable) [README]
Custom small pages (HTML/Markdown) alongside the link collection [README]
Optional title and subtitle on the front page, both configurable [README]
Custom HTML header additions for analytics scripts or style tweaks [README]
Custom footer with HTML support [README]

Server configuration:

Configurable host, port, and context path for reverse proxy setups [README]
Log level control (ERROR / WARN / INFO / DEBUG) with optional JSON log format [README]
Context path support (/portkey style subpaths) for nginx/Caddy reverse proxies [README]

Metrics:

Optional Prometheus metrics endpoint on a separate port [README]
Off by default; enable with enableMetrics: true and configure metricsHost/metricsPort [README]

Deployment:

Docker image on Docker Hub (codehat/portkey) [README]
Pre-built binaries for download (no compile step needed) [README]
Single binary — no runtime dependencies, no database [README]
Environment variable overrides for all config values [README]

What it doesn’t have:

No service health checks or ping indicators
No widgets (weather, calendar, RSS)
No user authentication or multi-user support
No admin GUI — everything is YAML-only
No plugin system

Pricing: SaaS vs self-hosted math

There is no SaaS version of portkey. The entire product is self-hosted.

Software cost: $0. AGPL-3.0 license means you can run it freely. The AGPL clause requires that if you modify the source and offer it as a network service to others, you must publish those modifications — but for personal or internal use, there’s no practical impact [README][GitHub].

Infrastructure cost:

Homelab (Raspberry Pi, NAS, existing server): $0 incremental
Minimal VPS (Hetzner CX11, 1 vCPU, 2GB RAM): ~$4–6/month
The Go binary is small enough that portkey will share a VPS comfortably with a dozen other services

Comparison basis: portkey isn’t replacing a paid SaaS you’d otherwise subscribe to. The honest comparison is against your browser’s built-in new-tab page, a Notion dashboard, or a pinned bookmarks toolbar. The cost argument is about convenience and control, not dollar savings.

If you’re already running a homelab with a reverse proxy, the marginal cost of adding portkey is one Docker Compose entry and fifteen minutes of config time.

Deployment reality check

The install path is clean. Download a pre-built binary from the GitHub releases page, drop it somewhere in your PATH, create a config.yml, run portkey. That’s it. No package manager, no runtime, no database [README].

For Docker (the more common path in homelab setups):

services:
  portkey:
    image: codehat/portkey
    ports:
      - "1414:1414"
    volumes:
      - ./config.yml:/app/config.yml:ro

Default port is 1414 (configurable). Add Caddy or nginx in front for HTTPS and a domain name. The contextPath setting handles subpath hosting cleanly if you’re running multiple services under one domain [README].

Realistic time estimates:

Technical user with Docker already running: 10–20 minutes to a working instance
Non-technical user following a guide from scratch: 1–2 hours including VPS setup and reverse proxy

What can go sideways:

The AGPL-3.0 license is occasionally a concern in corporate environments — if your legal team has a blanket “no AGPL” policy, check before deploying
No hot-reload documented — configuration changes may require a container restart
The project has one maintainer; if development stops, you’re maintaining a frozen Go binary (though that’s not inherently bad for a stable, simple tool)
No authentication layer — if you expose this to the public internet without a reverse proxy auth guard, your link collection is public

Pros and Cons

Pros

Genuinely zero-dependency. Single Go binary, single YAML file. No database, no Redis, no Node runtime. This is the deployment footprint you actually want for a startpage [README].
Keyword search shortcuts. Turns the portal into a lightweight address bar replacement — type a keyword, land on your service. Underrated feature for heavy keyboard users [README].
Prometheus metrics. Optional, off by default, on a separate port so it doesn’t contaminate the main app’s surface. A signal that the developer thought about production use [README].
Context path support. Subpath hosting works correctly, which a surprising number of small tools get wrong [README].
Live demo available. You can see exactly what you’re getting before deploying anything [README].
539 commits, active changelog. Not abandoned; the project has real commit history [GitHub].
Dark/light mode. Works without JavaScript hacks; it’s a first-class feature [README].

Cons

100 stars. Small project with one maintainer. No community, no forum, no plugin contributions, no public roadmap. If the developer stops showing up, the project stops moving [GitHub].
AGPL-3.0, not MIT. Less permissive than you might want if embedding in a product. For personal use it doesn’t matter, but for commercial operators it’s a consideration [GitHub].
No service health checks. Homarr, Homer, and Dasherr all show whether your services are actually responding. portkey shows a static link. If the linked service is down, the link is just dead [README].
No widgets. No weather, no calendar, no RSS, no system stats. If you want a dashboard, this is not it [README].
YAML-only configuration. There is no admin GUI. Every change requires editing a file and restarting. This is a feature for some people and a dealbreaker for others [README].
No authentication. If you expose portkey publicly without an auth layer on your reverse proxy, the page is readable by anyone [README].
No independent reviews. At 100 stars there are no third-party write-ups, no community forum threads, no “how I run it in production” blog posts. You’re on your own if something breaks oddly.

Who should use this / who shouldn’t

Use portkey if:

You run a homelab and want a lightweight startpage to organize links to your self-hosted services — Jellyfin, Nextcloud, Gitea, Grafana, etc.
You prefer config-as-code over clicking around a GUI to manage things.
You want the absolute minimum Docker footprint — no database, no secondary services.
You already have a reverse proxy and just need something to put at the root domain.
You want keyword search shortcuts to replace browser bookmarks.

Skip it (pick Homarr instead) if:

You want service health checks, ping indicators, or integration with Docker to auto-discover containers.
You want an admin GUI for adding/editing links without touching YAML.
You want widgets — weather, calendar, clock, system stats.

Skip it (pick Homer instead) if:

You want a similar YAML-driven, static-file approach but with a larger community, more stars (~9,000+), and more configuration examples available online.
You want icons from popular icon packs included out of the box.

Skip it (pick Dasherr or Flame instead) if:

You want a bookmarks manager that works across multiple users or browser profiles.
You want a slicker interface with more visual customization.

Alternatives worth considering

Homer — the obvious closest comparison. YAML-driven static startpage, much larger community (~9,000 GitHub stars), more icon support, no database. If you’re uncertain between the two, Homer’s community is a practical advantage.
Homarr — richer feature set: drag-and-drop layout, Docker integration, service health checks, widgets. React-based, heavier to run. The right choice if you want a proper homelab dashboard rather than just a link collection.
Dasherr — minimal static HTML/JS startpage, no server required, can run from a browser directly. Even lighter than portkey if you don’t need server-side features.
Flame — Node.js-based, has a built-in admin panel, bookmark management, and Kubernetes annotation support for service discovery. More opinionated but more powerful.
Fenrus — Go-based like portkey, supports app integrations (weather, search, Sonarr/Radarr), includes an admin GUI. More feature-rich, more complex.
Heimdall — PHP-based, more mature, supports app tiles with embedded service stats. Requires more infrastructure (PHP + database) but has broader application support.

For someone who wants a dead-simple link collection with near-zero maintenance overhead, the honest shortlist is portkey vs Homer. Pick portkey if you want slightly simpler setup and don’t need Homer’s icon ecosystem. Pick Homer if you want community support and more configuration examples available via search.

Bottom line

portkey does one thing: shows a page of links with a search box. It does that thing in a Go binary with no dependencies, configured in one YAML file, deployable in under twenty minutes. That’s its entire value proposition and it doesn’t oversell it. The tradeoffs are real — no health checks, no widgets, no GUI, no community to speak of — but if those tradeoffs fit your use case (organized homelab startpage, config-as-code, minimal footprint), portkey delivers exactly what it promises. The 100-star count is a risk signal for long-term project viability, not for today’s functionality. Homer covers the same niche with a much larger community if that matters to you. If it doesn’t, portkey is a clean choice.

Sources

Primary sources:

GitHub repository and README — kodehat/portkey (100 stars, AGPL-3.0 license, CodeHat). https://github.com/kodehat/portkey
Official demo site — https://demo.portkey.page
Official website — https://portkey.page

Note: The third-party articles provided during research ([1]–[5]) describe Portkey.ai, an unrelated enterprise LLM gateway product that shares the same name. Those sources were not used in this review to avoid misattribution.