gethomepage

홈서버의 대문 페이지를 glanceapp/glance 로 구성했는데 가벼워서 좋네 gethomepage/homepage 가 더 많이 쓰이는건 같은데 homepage는 next.js라서 무거워. 똥컴에는 golang이 더 좋아

My self-hosting graveyard is longer than the list of survivors I didn't set up my first server for anything this post is about (for reasons of my own, that part stays a secret under seven seals:D), but it very quickly found a perfectly legitimate and much more boring purpose: I needed a place to deploy my own pet projects - for tests, for demos to friends, to poke at something live instead of localhost - without running into Vercel and Render with their free tiers, strict per-service limits and subscriptions that grow faster than my projects do A VPS has only one limit, the hardware, and as it turned out, that's much easier to negotiate with than someone else's price list ;) Then I noticed that most of the time this hardware just sits idle, and I asked myself a fair question: what exactly am I paying for? Right around then I stumbled on the awesome-selfhosted repo, and down the rabbit hole I went… :D Right now there are three machines, not counting my main PC: a small rented VPS in Europe with 3 gigabytes of memory and 30 gigabytes of disk, which everything that has to be reachable from the internet goes through; a home server that lives at my family's place, because electricity and internet are simply cheaper there; and a small VPS for learning and doing scary things by hand (so I don't end up restoring the production box from backups), with 1 gigabyte of RAM and about 10 gigabytes of disk The home media server runs a Ryzen 3 PRO 3200G, 12 gigabytes of memory, a 480-gigabyte system SSD and two hard drives: a 4 TB WD Gold for everything valuable and an 8 TB Toshiba N300 for media They're called tank and junk, and I don't think I need to explain which is which :D Tank needs a second drive to mirror it, so the backups don't live on a single disk, but storage prices are such that it's easier to buy a Chevrolet Camaro than a new hard drive that size, and good deals on the used market are rare The current one was a lucky find: about $80 for a WD Gold WD4002FYYZ with just over 200 power cycles and a couple of years of service (and of course I ran the tests, the drive is livelier than plenty of modern ones) In all honesty: of those 12 gigabytes, the system currently sees less than ten, because the CMOS battery on the motherboard is dead, so after every power cut it forgets my settings and once again generously hands two gigabytes to the integrated graphics, which a server with no monitor has roughly zero use for For about two months now I've been promising myself every weekend to swap the battery and take that memory back, but, as you can probably tell, I'm a lazy ass, and my weekends are taken up by more important things (lying around, doomscrolling Instagram reels, playing with my cat, sinking ten hours into Civilization V... you know how it is:D) The front door The VPS mostly hosts what glues everything else together and keeps it safe, plus a couple of things I use every day My blog: about a hundred megabytes Homepage: a start page with a tile for every service Out of the box it's boring, and I wanted something pretty, so mine has glass, a background and my own palette, and I use it quite often, because its UI and UX really are great Uptime Kuma: monitoring Strictly speaking, having a server check whether it's still alive is a so-so idea, and once mine was down for half an hour without anyone noticing, but it keeps a proper eye on the containers, and that's why I keep it (the obvious fix is to run it on the home server and watch the VPS from outside, it's on the list) Beszel: CPU, memory and disk graphs for every machine Right now it just sits there: Kuma and Termix cover pretty much everything I need from it, so Beszel is like that distant relative you used to be really close to and now call once a year :D Termix: SSH right in the browser Nexterm lived exactly one day before it, and Termix stayed because it won on every count at once: features, easy setup, convenience, looks and snippets, and I honestly don't know how I managed servers from my phone before them Memos: notes where I write down absolutely everything, and it has completely replaced Saved Messages in Telegram for me I'm a fan of minimalism and simplicity, and I don't see the point of an app where I'll never touch most of the features, and most importantly, it's self-hosted, btw The idea of bolting AI onto it for tags and summaries is sitting in the backlog: there are higher-priority projects right now, but SOMEDAY I'll automate this part of my life:D MeshCentral: remote access to my main PC All my code and Claude Code live on it, and I often work away from home, so I needed access from anywhere, right in the browser, without installing anything on the machine I'm connecting from Donetick: household chores for the family, and right now it's on pause, because I still have questions about the interface and some of the features But it comes with my favorite story: I forked its web app to translate it, and it turned into a full i18n integration and some real help for the maintainer, so now I'm listed as a contributor in donetick/frontend Vaultwarden: a password manager I used Google Password Manager for years, and that was perfectly fine right up until I started running my own services and suddenly realized I was seriously worried about where and how my data was stored, and since I'm running a server anyway, it made sense to keep my passwords there too Pocket ID: passkey sign-in to almost all my services, no passwords When you have twenty services, typing a password into each one gets old within half an hour, and I also wanted my self-written MCP servers to sit behind my own security layer, not behind some third-party platform I'd have to take at its word Backrest: nightly backups that go to the cloud and then get pulled home Knock on wood, I haven't had to restore from them yet, apart from a test run, and I picked it because I like seeing what's actually happening: I enjoy working in the console, but a UI is still more familiar and more pleasant IT-Tools: a set of small converters and generators It can stay :D And two of my own pet projects: MindAmp, mind maps with an LLM layer that speeds up the work and boosts the research part with agents, no third-party subscriptions needed, and VigilAMP, a registry of my projects and their current status that keeps me from getting lost in what I'm working on and what stage it's at All of this fits into one and a half gigabytes of memory, with about as much left in reserve, and the disk is 85% full Yes, I know, and no, I'm not doing anything about it today:/ The warehouse The home server is for the heavy stuff: things that take up a lot of space, and things I'd rather not keep on rented hardware The rule here is simple: I test a service on myself first and only then bring the family in, which is why some of these are still just mine Nextcloud with OnlyOffice: my files and documents, a replacement for Google Drive, which is now just a backup People often call Nextcloud heavy, and the numbers I'd read were scary: 1-1.2 GB of RAM against 300-400 MB for Seafile, so I was all set to go with Seafile Then I decided not to take it on faith and ran both side by side on the home server At idle, the whole Seafile stack (Seafile, MariaDB, memcached) sat at about 450 MiB, and Nextcloud with Postgres and Redis at about 270 Right now the Nextcloud stack, cron included, idles at around 240 MiB, and with OnlyOffice on top it's about 415, roughly 4% of the 9.6 GB my dead battery lets me have OnlyOffice is the only container with a cap (2 GB), because it spins up a worker for every open document and easily climbs into the hundreds of MB while someone's editing These are idle numbers Previews and big syncs make Nextcloud heavier, and my setup is gentle: SSD, LAN only, not much data Still, I haven't run into any problems, it's stable and pretty spry, and on my hardware the memory argument fell apart, so Nextcloud stayed and Seafile went (I could be wrong, ofc, but I'm too lazy to test it under load, and I don't use it that much anyway: it's basically a glorified file dump with a few nice apps that let me get to my files from anywhere) Immich: photos, a great Google Photos replacement, and it's still at the "me first" stage before I bring the family in BookLore: a book library, and I chose it for FB2 support, because my whole library is in that format So far I'm the only one using it BookLore has since gone into maintenance mode, and its developer named BookOrbit as the official successor, so right now I'm trying it out next to BookLore, but I don't have an opinion on it yet Jellyfin: movies and TV shows It's fully open and free, does exactly what it needs to, and these days we watch almost everything I own through it at home SearXNG: a metasearch engine, set up for privacy and security, like most of my services I've barely used it seriously yet Navidrome: my music library, and I listen to it every day: all my music goes through it now, no subscriptions, no limits On my PC I listen through Psysonic, and on my phone through Solound The graveyard The list of things I've removed is longer than the list of things that run, and every one of the deceased had its own cause of death And these are just the ones worth a eulogy: in total around fifty services got installed and then deleted Some got a second chance, like Dashy and Karakeep, and Windmill filled the disk to 100% Ghost and Astro with Keystatic were my first two shots at my blog, and each lasted about two days Ghost brought a crowded communal apartment of other people's services, and Keystatic kept its admin on Vite's dev server, the one you're not supposed to expose to the internet So I ended up writing my own Finding a browser terminal took longer than I'd like ttyd dropped the connection every few minutes Cockpit worked, but I only needed it for the terminal and files, and dragging in a whole server control panel for that is overkill Nexterm was lightweight, but it was still in beta Termix won Seafile was supposed to be the lightweight one and lost to Nextcloud on memory (the numbers are up in the warehouse) Termix also finished off Portainer: it turned out I'd rather manage containers straight from the terminal than click through yet another panel Karakeep, bookmarks with previews, turned out to be three containers, 3.5 GB of images and 700 MB of memory Without the built-in Chrome for previews it's a completely different product, and keeping something like that on a VPS with three gigabytes is a luxury I can't afford Trilium was out because of its cluttered interface and broken built-in AI Minimalism, remember? Notes went to Memos in the end Anki Sync Server lasted two days: I set it up for my wife, my wife gave up on AnkiDroid, and there was nothing left to sync And Inbox Zero never even made it to installation: I wrote a whole spec for it and then decided I didn't need it (and there were security questions too, but that stays between us:D) My rule is this: every new service gets compared to what already works, and if it doesn't click quickly and isn't critical, it gets removed without hours of debugging, which is exactly why 3 gigabytes is still enough Why all this Partly for control: my photos and files sit on disks I can touch with my own hands, and my passwords at least live on a server I run myself But mostly for learning: I write backend in Python and I'm learning everything around the code, and the servers are my sandbox for that, from networking and Docker to backups, monitoring and security And when something breaks at three in the morning, it's my fault and my lesson ¯\_(ツ)_/¯ So what's in your graveyard, and what killed it?

Homepage Dashboard Docker Setup: Config, Widgets and Labels --- title: "Homepage Dashboard Docker Setup: Config, Widgets and Labels" published: true description: "Run the Homepage dashboard with Docker Compose: services.yaml, an Uptime Kuma widget, Docker label discovery and the fix for Host validation failed." tags: selfhosted, docker, homelab, dashboard canonical_url: deploylark.com --- Homepage is a static start page for a homelab. You describe services, bookmarks and widgets in YAML files, and it shows live data from the apps behind them, such as container stats, uptime and queue counts. On October 20, 2026, the gethomepage/homepage repository had about 33,200 GitHub stars, and v2.6.0 had shipped three days earlier. This guide runs v2.6.0 with Docker Compose, wires up an Uptime Kuma widget, discovers a container from Docker labels through a read-only socket proxy and fixes the Host validation failed error that trips up most first installs. TL;DR: - Run ghcr.io/gethomepage/homepage:v2.6.0 with ./config mounted at /app/config and port 3000 bound to 127.0.0.1. The first start writes default YAML files into that folder. - Set HOMEPAGE_ALLOWED_HOSTS to every host and port people or monitors use, comma-separated with no spaces. Only localhost:3000 and 127.0.0.1:3000 work without it. - After any env change, recreate the container with docker compose up -d. A docker compose restart keeps the old value. - For Docker stats and label discovery, point docker.yaml at a tecnativa/docker-socket-proxy container with CONTAINERS=1 and POST=0 instead of mounting the socket into Homepage. - Add homepage.* labels to any container and it shows up on the dashboard, widget included. Install Homepage with Docker Compose The compose file The Docker install docs show a single homepage service with an optional socket mount. This file adds a socket proxy, as the Docker integration docs suggest, plus two services for Homepage to watch: Uptime Kuma 2.5.6 and the tiny traefik/whoami web server. The official examples use :latest. Every tag here is pinned to what ran: !Diagram of the stack on the Compose network hp_default. A browser sends requests with Host homepage.lab.test:3000 to the homepage container, v2.6.0 on 127.0.0.1:3000, where the host is checked against HOMEPAGE_ALLOWED_HOSTS. Homepage reads labels, status and stats from dockerproxy, socket-proxy v0.5.0 with CONTAINERS=1 and POST=0, which mounts docker.sock read-only. Homepage also calls uptime-kuma 2.5.6 for the uptimekuma widget and whoami v1.12.0 for a customapi widget. Uptime Kuma polls homepage:3000/api/healthcheck, so homepage:3000 is an allowed host too. name: hp services: dockerproxy: image: tecnativa/docker-socket-proxy:v0.5.0 environment: - CONTAINERS=1 - POST=0 volumes: - /var/run/docker.sock:/var/run/docker.sock:ro restart: unless-stopped homepage: image: ghcr.io/gethomepage/homepage:v2.6.0 ports: - "127.0.0.1:3000:3000" volumes: - ./config:/app/config environment: HOMEPAGE_ALLOWED_HOSTS: ${HOMEPAGE_ALLOWED_HOSTS:-} depends_on: - dockerproxy restart: unless-stopped uptime-kuma: image: louislam/uptime-kuma:2.5.6 ports: - "127.0.0.1:3001:3001" volumes: - kuma-data:/app/data restart: unless-stopped whoami: image: traefik/whoami:v1.12.0 ports: - "127.0.0.1:8081:80" labels: - homepage.group=Lab - homepage.name=whoami - homepage.icon=traefik.png - homepage.href=http://127.0.0.1:8081/ - homepage.description=Discovered from Docker labels - homepage.widget.type=customapi - homepage.widget.url=http://whoami/api - homepage.widget.mappings[0].label=Hostname - homepage.widget.mappings[0].field=hostname - homepage.widget.mappings[1].label=Remote - homepage.widget.mappings[1].field=remoteAddr restart: unless-stopped volumes: kuma-data: Put the allowed hosts in a .env file next to it. The section on host validation below explains each entry: HOMEPAGE_ALLOWED_HOSTS=homepage.lab.test:3000,homepage:3000 Then start it: mkdir -p config docker compose up -d curl -s http://127.0.0.1:3000/api/healthcheck The health check answered 2.9 seconds after docker compose up -d. That curl works without an allowed-hosts entry only because the host port is 3000. When I published Homepage on 127.0.0.1:3900 instead, the same health check on the server returned 400 until 127.0.0.1:3900 was on the list. By default the container runs as root. The docs support PUID and PGID for a non-root user, and with the socket proxy Homepage does not need socket access at all. First start and the default config files Start with an empty ./config folder. After the first start and a few page loads, mine held settings.yaml, services.yaml, widgets.yaml, bookmarks.yaml, docker.yaml, kubernetes.yaml and proxmox.yaml, plus empty custom.css and custom.js files and a logs folder. Most of the YAML files start with a comment that links to their docs page. The default services.yaml holds three placeholder groups pointing at http://localhost/, the default widgets.yaml shows CPU, memory and disk usage plus a DuckDuckGo search box, and the default settings.yaml only has placeholder weather API keys. Edits to these files do not need a container restart. The settings docs say to click the refresh icon at the bottom right of the page to clear cached dashboard data. Logs go to config/logs/homepage.log as well as docker compose logs homepage. Add services and info widgets services.yaml with an Uptime Kuma widget A service entry is a card with a name, icon, link and description. Add server and container to show a status dot and container stats, and add a widget block to pull data from the app API. The Uptime Kuma widget reads a single status page, so create one in Uptime Kuma first. This one has the slug lab and two HTTP monitors, one for whoami and one for the Homepage health check: --- - Monitoring: - Uptime Kuma: icon: uptime-kuma.png href: http://127.0.0.1:3001/ description: Status page lab server: lab-docker container: hp-uptime-kuma-1 showStats: true widget: type: uptimekuma url: http://uptime-kuma:3001 slug: lab The widget URL uses the Compose service name, because the request comes from the Homepage container, not from the browser. Homepage looks up icon names in the Dashboard Icons set, so you only type the name. !Homepage v2.6.0 dashboard in the dark slate theme. The top bar shows CPU at 3%, 8 GiB memory free, 116 GB disk free, the date Oct 20, 2026, 10:14 AM and a search box. The Monitoring group has an Uptime Kuma card with container stats, 1% CPU, 145 MB memory, 143 kB RX and 3.58 MB TX, and the Uptime Kuma widget showing 2 sites up, 0 sites down and 67% uptime. The Lab group has a whoami card, discovered from Docker labels, with a customapi widget showing the container hostname and the remote address 172.21.0.5:43146. A Docs bookmarks section lists Homepage docs and Uptime Kuma wiki. The footer reads v2.6.0 (51cc168, Oct 17, 2026). The 67% is the average 24-hour uptime of every monitor on the status page, which is how the widget computes it. When the screenshot was taken, whoami stood at 100% and the Homepage monitor at 33%, because two of its three checks had failed with HTTP 400. The host validation section below explains why. widgets.yaml and settings.yaml Info widgets sit in the bar across the top. This file keeps the resources and search widgets from the defaults and adds a clock: --- - resources: cpu: true memory: true disk: / - datetime: text_size: md format: dateStyle: medium timeStyle: short - search: provider: duckduckgo target: _blank Theming and layout live in settings.yaml. The settings docs cover the full list. These keys set a dark theme with the slate palette, boxed headers, status dots instead of text, and a two-column row layout for each group: --- title: Lab dashboard theme: dark color: slate headerStyle: boxed statusStyle: dot layout: Monitoring: style: row columns: 2 Lab: style: row columns: 2 Use background for a wallpaper image and custom.css in the config folder for anything the settings do not cover. Docker integration and label discovery docker.yaml through a socket proxy Homepage talks to the Docker API for container status, CPU and memory stats, and label discovery. The docs offer two ways in. Mounting /var/run/docker.sock into Homepage works, but the docs note that "In order to use the socket directly homepage must be running as root", and socket access gives full control of the host. The :ro mount flag does not change that, because it doesn't limit the Docker API. The safer route is a socket proxy that only exposes read endpoints. Point docker.yaml at it: --- lab-docker: host: dockerproxy port: 2375 lab-docker is just a name. Service entries refer to it with server: lab-docker. The proxy listens on port 2375 inside the Compose network only, with no published port. With CONTAINERS=1 and POST=0, curl from another container on the same network got these results: GET /containers/json 200 POST /containers/<id>/restart 403 GET /images/json 403 So Homepage can list containers and read stats, but it cannot restart anything or browse images. If you run Docker Swarm, the docs add SERVICES=1 and TASKS=1 to the proxy. Labels on the container Automatic discovery reads homepage.* labels from every container the Docker server can see. The keys mirror the YAML in services.yaml, written with dots. The whoami container in the compose file above carries a group, name, icon, link and description, plus a customapi widget that calls the whoami JSON endpoint and maps two fields: labels: - homepage.group=Lab - homepage.name=whoami - homepage.icon=traefik.png - homepage.href=http://127.0.0.1:8081/ - homepage.description=Discovered from Docker labels - homepage.widget.type=customapi - homepage.widget.url=http://whoami/api - homepage.widget.mappings[0].label=Hostname - homepage.widget.mappings[0].field=hostname - homepage.widget.mappings[1].label=Remote - homepage.widget.mappings[1].field=remoteAddr Nothing about whoami is in services.yaml. After docker compose up -d, the Lab group appeared with the whoami card, a green status dot from the container state and the two mapped values, visible in the dashboard screenshot above. The Remote value is an address on the Compose network, because Homepage makes the widget request from its own container, not from the browser. The docs say the server and container values are inferred for discovered services, and the whoami card needed neither label. To keep one dashboard from picking up labels meant for another, the docs describe instanceName in settings.yaml with matching homepage.instance.<name>.* labels. The same pattern works for real apps that have a native widget. A Paperless-ngx or Nginx Proxy Manager container can carry its own homepage.widget.type and API credentials as labels, so the dashboard entry lives next to the service it describes. Fix Host validation failed with HOMEPAGE_ALLOWED_HOSTS What the error looks like Since v1.0.0, released on March 14, 2025, Homepage checks the Host header of every API request. The installation docs list it as the one required variable for reaching Homepage through any URL other than localhost. If the host is not on the list, the page and its API calls, /api/healthcheck included, return HTTP 400. This is the response to Host: homepage.lab.test:3000 before the variable was set: !Terminal capture from the lab. A curl request with Host homepage.lab.test:3000 to 127.0.0.1:3000/api/services returns HTTP 400 with the JSON error Host validation failed. See logs for more details. The Homepage log shows error: Host validation failed for: homepage.lab.test:3000 and the hint to set the HOMEPAGE_ALLOWED_HOSTS environment variable. After setting HOMEPAGE_ALLOWED_HOSTS=homepage.lab.test:3000,homepage:3000 in .env and running docker compose up -d homepage, the same request returns 200 and a request with Host evil.example:3000 still returns 400. The log line names the exact host and port that failed. Copy that value into the variable. Requests to http://127.0.0.1:3000 and http://localhost:3000 always pass, which is why a first test on the server itself often works and the same dashboard breaks from a laptop on the LAN. That only covers port 3000. If you map another host port, such as 8080:3000, add 127.0.0.1:8080 or the LAN address with :8080, as users found in discussion #4920. A second case is easy to miss. Uptime Kuma checked http://homepage:3000/api/healthcheck from inside the Compose network, so its requests arrived with Host: homepage:3000. That monitor went Down at 10:12:15 with HTTP 400 and came back Up at 10:14:15, right after homepage:3000 joined the list. Any monitor, reverse proxy or script that reaches Homepage by container name needs that name on the list too, port included. Our Uptime Kuma guide covers setting up that kind of HTTP monitor. !Uptime Kuma 2.5.6 detail page for the Homepage monitor, which checks http://homepage:3000/api/healthcheck every 60 seconds. The heartbeat bar shows two red beats followed by green ones and the status is Up. Uptime for 24 hours, 30 days and 1 year reads 66.67 percent. The event list shows Down at 2026-10-20 10:12:15 with Request failed with status code 400, then Up at 10:14:15 with 200 - OK. This screenshot came a few minutes later than the dashboard one. By then four of the monitor's six checks had passed, so its own uptime read 66.67%. The value to set, and recreate the container The value is a comma-separated list with no spaces. Include the port whenever the browser URL has one: HOMEPAGE_ALLOWED_HOSTS=homepage.lab.test:3000,homepage:3000 Behind a reverse proxy on port 443, the browser sends the bare domain, such as dash.example.com, so that is the entry. With that list, homepage.lab.test:3000 and homepage:3000 returned 200, and evil.example:3000 still returned 400. Then recreate the container. I added a third host to .env and ran docker compose restart homepage. Inside the container, the variable still held the old two hosts and the new host got 400. After docker compose up -d homepage, the variable held all three and the request returned 200. Maintainer shamoon wrote in discussion #5033: "You need to re-create a container when you change env variables, not just restart." Check what the container really sees with docker compose exec homepage env | grep ALLOWED. Setting the variable to * turns the check off. The docs do not recommend it and add that "the built-in host check is a best-effort guard for local setups and is not a substitute for edge protections." Secure and run Homepage Put authentication in front of it Homepage shows internal hostnames and links, and its API proxy calls your services with the keys from your config. Keep it on 127.0.0.1 or a private network and publish it through a reverse proxy with TLS, as in the Nginx Proxy Manager guide. Since v2.0.0 Homepage also includes an optional login gate, which this guide doesn't turn on. The installation docs list HOMEPAGE_AUTH_ENABLED=true, a HOMEPAGE_AUTH_SECRET of at least 32 characters, HOMEPAGE_EXTERNAL_URL, and either HOMEPAGE_AUTH_PASSWORD or OIDC settings. The same docs warn that Homepage does not rate limit password attempts, so a proxy or VPN should still sit in front of any public instance. Keep to the newest release as well. v2.6.0 fixes GHSA-qxcr-4rv3-v23r, a high-severity bypass of that login gate in versions 2.0.0 to 2.5.0. API keys do not need to sit in plain YAML. Per the Docker install docs, the value of any HOMEPAGE_VAR_NAME environment variable replaces <code>&#123;&#123;HOMEPAGE_VAR_NAME&#125;&#125;</code> in the config, and HOMEPAGE_FILE_NAME points at a file, such as a Docker secret, whose contents replace <code>&#123;&#123;HOMEPAGE_FILE_NAME&#125;&#125;</code>. Resource use Homepage is light. At idle, docker stats showed these averages for the four containers: | Container | Memory | CPU | | --- | --- | --- | | homepage v2.6.0 | 116.5 MiB | 0.00% | | uptime-kuma 2.5.6 | 139.6 MiB | 0.41% | | docker-socket-proxy v0.5.0 | 22.3 MiB | 0.00% | | whoami v1.12.0 | 2.4 MiB | 0.00% | | Total | 280.8 MiB | 0.42% | Homepage never went above 0.04% CPU. It fits next to heavier apps on a small VPS, such as a Coolify host or a box that also runs Plausible. FAQ Host validation and setup Why does the error stay after setting HOMEPAGE_ALLOWED_HOSTS? Usually the container was restarted, not recreated, so it still has the old environment. Run docker compose up -d and check with docker compose exec homepage env. In discussion #5033 and discussion #5412, the maintainer's answer to this error was to recreate the container, not just restart it. The #5412 user ran Homepage through TrueNAS apps and then Dockge, so check how your stack manager recreates a container. Does HOMEPAGE_ALLOWED_HOSTS need the port? Yes, whenever the URL has one. The check compares the full Host header, so 192.168.1.10:3000 and 192.168.1.10 are different entries. Discussion #4920 also shows that a reverse proxy can change the Host header, so match the value printed in the log. Can the list contain spaces? No. The docs specify a comma-separated list with no spaces, and discussion #4789 traces a failing setup to a space after a comma. Widgets and Docker Why does a widget show API Error? The widget call from Homepage to the service failed. The troubleshooting page suggests the API Error Information button on the widget, then config/logs/homepage.log, and LOG_LEVEL=debug for more detail. Check that the widget URL works from inside the Homepage container. A container name like http://uptime-kuma:3001 works there, localhost does not. Why are containers with homepage labels not showing up? Homepage needs a working Docker connection in docker.yaml, and the labels should include homepage.group and homepage.name, as in the docs examples. With the socket mounted directly, Homepage must run as root or have socket access, a common cause in discussion #3124. A socket proxy with CONTAINERS=1 avoids the permission problem. Is mounting docker.sock into Homepage safe? It works, but it hands the container full control of Docker. The Docker integration docs point to a socket proxy for that reason. With POST=0, the proxy above refused a container restart with 403 while still serving the container list. Originally published on DeployLark: Homepage Dashboard Docker Setup: Config, Widgets and Labels

自建服务太多，访问地址记不住？🏠 Homepage 把 NAS、Docker 和常用站点放进一张入口页。 查看状态也更顺手。🧭 gethomepage/homepage #HomeLab #SelfHosted #浇朋友 #蓝朋友 #互关 #fo

One dashboard for your home server 🏠 Homepage puts app shortcuts and service info in one customizable start page. Configure it with YAML for your homelab. 📡 gethomepage/homepage #SelfHosted #Dashboard #浇朋友 #蓝朋友 #互关 #fo

Homepage is a self-hosted dashboard that pulls Docker, Kubernetes and service status onto one page. 33k stars, still shipping today. gethomepage/homepage

Had a lot of fun vibing these yesterday homepage-local Config, helper services and tooling for a self-hosted gethomepage/homepage dashboard (v2.4.0). It is built from source and runs natively, not in Docker, in Proxmox LXC CT 106 homepage-local at xxx.xxx.xxx.xxx. The dashboard has two tabs: - Overview has Proxmox and PBS graph panels, an Omada Network section, Synology NAS cards and core services. - Apps has per-app cards that show guest and container health, CPU, memory, uptime and network totals. It has a dark slate theme and an optional Starbucks palette. A light/dark toggle sits in the footer. >This is a private homelab repo. It holds no secrets. Credentials live only in /etc/homepage.env on CT 106 and are referenced by HOMEPAGE_VAR_* name. Layout |Path|Purpose| |:-|:-| |new-config/|Local copy of /opt/homepage/config on CT 106 (YAML, custom.css, custom.js). This is the source of truth for what is deployed.| |tools/gen_services.py|Generates the top service groups (Proxmox, Omada Network, Synology Apps, Services) into new-config/services.yaml. That file is generated; never edit it by hand.| |tools/apps-groups.yaml|Source of truth for the Apps-tab cards.| |tools/check.py|Consistency checks: generator freshness, YAML parsing, layout group names, the custom.js couplings, the --px-* CSS variables, and highlight thresholds vs graph colours. Run via ./deploy.sh check.| |tools/check_negative.sh|Breaks one coupling per case to prove check.py catches it. Run after editing check.py.| |deploy.sh|Validate, compare, back up and deploy to CT 106 (see Deploying).| |nas-stats/|Helper (port 3198) for DSM, Download/File Station, qBittorrent, Uptime Kuma, PBS and Docker.| |npm-stats/|Helper (port 3199) for Nginx Proxy Manager.| |omada-stats/|Helper (port 3197) for the read-only Omada controller API, with a pinned public CA certificate.| |guest-stats/|Helper (port 3196) for per-guest and per-container stats on the Apps tab.| |proxmox-stats/|Helper (port 3195) that provides PVE/PBS history for the graph panels.| |helper-health/|LAN endpoint (port 3194) that aggregates the helpers' /health for Uptime Kuma.| |glances/|systemd unit for the Glances REST API on the Proxmox host (header widget).| |homepage/|systemd drop-in for fast homepage.service stops, and VERSION, the deployed Homepage commit (./deploy.sh record-version).| How it fits together Browser -> Homepage :3000 (CT 106) |- built-in widgets (adguard) |- customapi widgets -> PVE, PBS, WGDashboard, AdGuard, Docker socket proxy '- customapi widgets -> 127.0.0.1 helpers (login sessions, caching, filtering) Uptime Kuma (CT 115) -> helper-health :3194 /health (LAN) -> each helper's /health Homepage's customapi widget can't hold login sessions, so each helper logs in to its upstream, caches the result and exposes a small JSON endpoint on 127.0.0.1. Every helper is a single Node 22 file with no npm dependencies and serves cached data for up to 5 minutes if its upstream fails. Each runs as a systemd service on CT 106, sandboxed with NoNewPrivileges, PrivateTmp, ProtectHome and ProtectSystem=strict. The one helper that writes state, omada-stats, uses StateDirectory=omada-stats (/var/lib/omada-stats/). Every helper also answers GET /health: 200 when all its routes can produce data, otherwise 503 naming the failing routes. Only helper-health listens on the LAN. It runs as a DynamicUser with no env file and returns only status codes and failing route names, never helper data. Uptime Kuma monitor "Homepage helpers" polls it every 60 s. On the dashboard, a Proxmox graph panel whose data has not changed for 10 minutes falls back to the card's plain tiles. Development ./deploy.sh check # the full local gate: consistency checks, node --check, all unit tests # Regenerate the generated service groups python3 tools/gen_services.py # set GEN_OUT to change the output path Edit tools/gen_services.py or tools/apps-groups.yaml, then re-run the generator. Direct edits to new-config/services.yaml are overwritten by the next run, and check.py fails if the committed file is stale. Unit tests sit next to each helper as server.test.js. nas-stats/server.http.test.js runs the real server against a stub qBittorrent to cover re-login and stale-cache serving. guest-stats/server.http.test.js does the same against a stub PVE and Docker API to cover routing, 404s, query strings and /health. Deploying ./deploy.sh status # read-only: local vs CT 106 (config, helper files and unit files) ./deploy.sh backup # vzdump snapshot of CT 106 ./deploy.sh deploy [config|helper|all] # check, back up changed files remotely, copy, restart ./deploy.sh deploy --rebuild config # also rebuild Homepage ./deploy.sh record-version # write the deployed Homepage commit to homepage/VERSION deploy always runs the full check first and asks for confirmation (--yes skips it, --dry-run prints the remote commands). Rebuild whenever you add or remove cards, or change the number or order of widgets on a card; it needs a temporary memory bump to 3 GB, so a build in 1 GB will OOM. deploy.sh does not install the helpers' systemd unit files; those are pushed by hand (HANDOVER.md §3), and status reports when they drift. Take a vzdump 106 before big changes and keep *.pre-<step> rollback copies. These are git-ignored, as are backups/ and screenshots. Afterwards, verify in a browser, with no "API Error" and card heights in a row within about 20 px.