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 ~/homepage

Everything 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-stopped

Value 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.sock

4.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: audiobookshelf

How 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.com

Swap 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 -d

Open 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.


A dashboard you only open when something is already broken is a static file with a port.

To make the visual change stick:

  1. Install Custom New Tab URL (Chrome / Brave / Edge) or New Tab Override (Firefox).
  2. Paste the dashboard URL (http://YOUR_VPS_IP:3000) into the extension settings.
  3. 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.