Self-hosted Dashboard
Or: make the VPS impossible to forget by putting it on every new tab.
Source: /Users/nitishchauhan/Downloads/Self-hosted Dashboard.md
Phase: final
Index: Index - Self-hosted Dashboard
Trajectory: Trajectory - Inner Map
Pipeline: CONSTITUTION - Publishable Asset Pipeline · 00 - Master Index
Status: draft
Mode: Experiential
How this one actually started
The problem was not “I need another pretty home page.”
The stack was already real: uptime checks, a local PDF tool, media library storage, containers that either run or quietly die. What was missing was a single dense surface that showed host health and app status without opening five tabs and hoping memory was current.
I was already in Cursor on the VPS path. So the ask was blunt: skip the decorative dashboards. Ship a production-grade, data-dense command center that talks to Docker, and give me files I can paste and execute, not a product roundup.
What follows is that blueprint, kept as executable value, with the habit move that actually makes the config matter.
The real question under the ops itch
Is the win more links on a grid, or a live map of what the machine is doing that you cannot avoid looking at?
This piece stays on the second answer: Homepage wired to Docker, three YAML files as the living layout, then the new-tab lock so infrastructure becomes the default browser state. Domain polish waits until IP:3000 already works.
1. Pick the command center, not another bookmark wall
Homepage (gethomepage) is the chosen stack here: modern, minimal, dense enough to hold system widgets and application tiles, and native enough to Docker that you are not fake-static about container state.
Target shape (architecture before files):
+-----------------------------------------------------------------------+
| YOUR VPS IP / DOMAIN |
+-----------------------------------------------------------------------+
| [ HOMEPAGE DASHBOARD ] |
| +-----------------------------------------------------------------+ |
| | SYSTEM [||||||||............] CPU: 38% [||||||||||||] RAM: 52% | |
| +-----------------------------------------------------------------+ |
| | NET SERVICES | |
| | [ Uptime Kuma ] --------> Status: Online | |
| | [ Stirling-PDF ] -------> Local PDF toolkit | |
| | [ Audiobookshelf ] ----> Storage / library surface | |
| +-----------------------------------------------------------------+ |
+-----------------------------------------------------------------------+If that picture is wrong for your stack, swap the tiles. Do not swap away the idea: system row first, core apps second, external bookmarks third.
2. Project directory
Central home for config on the VPS:
mkdir -p ~/homepage/config
cd ~/homepageEverything below assumes that root. Cursor’s job is to create the paths and files; yours is to replace YOUR_VPS_IP and container names with reality.
3. Core Docker blueprint (docker-compose.yml)
Create docker-compose.yml in ~/homepage. This mounts config and hooks Homepage into host Docker via the socket so container status is not a manual checkbox.
services:
homepage:
image: ghcr.io/gethomepage/homepage:latest
container_name: homepage
ports:
- 3000:3000
volumes:
- ./config:/app/config # layout configuration
- /var/run/docker.sock:/var/run/docker.sock # live container status
restart: unless-stoppedValue of the socket mount: zero-friction local metrics and container state without inventing a second agent just to learn “is it up.” Treat socket access as personal-ops power; do not expose Homepage carelessly to the public internet without later hardening.
4. Three-file visual config (~/homepage/config)
The dashboard is not a black-box UI tour. It is three YAML surfaces you can version and edit like code.
4.1 System resources (settings.yaml)
Global layout plus Docker provider so the top of the page can carry live performance context.
---
# Layout styling configuration
layout:
System:
style: row
columns: 2
# Show live system performance metrics natively
providers:
docker:
url: /var/run/docker.sock4.2 Visual row grid (services.yaml)
First row: high-density system visualisers. Second row: application links with live status indicators. Replace IPs, ports, and container names.
---
# First Row: High-density system visualisers
- System Resources:
- VPS Server:
icon: si-linux
widget:
type: glances
url: http://localhost:3000 # point at a real Glances (or supported) metrics endpoint in your stack
public: true
metrics:
- cpu
- memory
- disk
# Second Row: Your application links with live status indicators
- Core Applications:
- Uptime Kuma:
icon: si-uptimekuma
href: http://YOUR_VPS_IP:3001 # change to your actual ports
description: Real-time network status and ping graphs
server: docker
container: uptime-kuma # automatically reads container state
- Stirling PDF:
icon: si-adobe-pdf
href: http://YOUR_VPS_IP:8080
description: Local visual PDF layout processor
server: docker
container: stirling-pdf
- Audiobookshelf:
icon: si-podcast
href: http://YOUR_VPS_IP:1337
description: Visual media library storage engine
server: docker
container: audiobookshelfHow to read this file: services.yaml is the living map of your stack. When you add a service, you add a tile. When a container name is wrong, the tile teaches you that before a longer debug loop does.
4.3 Quick-launch utilities (bookmarks.yaml)
External resources for research or dual-encoding habits (learning feeds, reference surfaces). Not Docker-bound.
---
- Learning Engines:
- Reddit Infographics:
- icon: si-reddit
href: https://reddit.com
- Pinterest Feed:
- icon: si-pinterest
href: https://pinterest.comSwap these for whatever you actually open daily. The point is one grid for infra and one strip for attention inputs.
5. Spin it up
From ~/homepage:
docker compose up -dOpen http://YOUR_VPS_IP:3000.
You should see a dense, responsive console: live CPU and memory style readouts (once metrics wiring is honest for your host), storage context, and links into running software. If a tile is wrong, fix YAML and reload. Prefer small config edits over installing a second dashboard product.
6. The final link: lock it to browser time
A dashboard you only open when something is already broken is a static file with a port.
To make the visual change stick:
- Install Custom New Tab URL (Chrome / Brave / Edge) or New Tab Override (Firefox).
- Paste the dashboard URL (
http://YOUR_VPS_IP:3000) into the extension settings. - Result: the split second you open the laptop or hit Ctrl+T, personal infrastructure is on screen.
That is the habit design half of the piece. Capture-first ops UI only works if the UI is the default surface.
7. Optional next hardening: reverse proxy and domain
Ship the IP version first. When you want a clean name instead of raw IP (and TLS in front of the panel), add a reverse proxy path such as Nginx Proxy Manager and point a subdomain at Homepage.
Do not block the first win on that step. Command center online and unavoidable comes before brand-clean URLs.
Open fork when ready: secure reverse proxy on the same VPS script so the dashboard is reachable at something like https://home.yourdomain.com instead of http://IP:3000.
What this thread was hunting
Not a catalog of every self-hosted start page.
A Cursor-executable Homepage command center: Docker socket for live state, three YAML files as the map of services and bookmarks, bring-up on port 3000, then a new-tab lock so the VPS stops living only in memory. Reverse proxy is polish after proof.
If you already know every container by heart, you still want the grid. Density beats recall when the stack grows.
Provenance: product-spec blueprint in Downloads → Index - Self-hosted Dashboard → this Final. Sibling stack themes may cross-link later (Excalidraw / OSS tooling indexes); this asset stays on Homepage + habit lock.