Wiki personal — Esteban Alcocer

Homepage (gethomepage) — dashboard de servicios, en vm-playground

Properties1
tagsdocker, homepage, cloudflare, tunnel, access

Se lee en 4 min

Homepage (gethomepage) — dashboard de servicios, en vm-playground

Instancia self-hosted de gethomepage (ghcr.io/gethomepage/homepage), un dashboard de enlaces a todos los servicios de la flota (personal-hub, Trivasa, Conkafecito), publicado en el apex de ehas.uk (sin subdominio) detrás de Cloudflare Access. Stack en ~/stacks/homepage/docker-compose.yml, config YAML en ~/stacks/homepage/config/ (services.yaml, settings.yaml, widgets.yaml, bookmarks.yaml).

Excepción al rol de workstation de vm-playground

Tercera excepción documentada al rol de vm-playground como workstation pura sin servicios de producción (ver hosts.md), junto a DBHub y conkafecito-observability — mismo motivo de fondo en los tres casos: el host ya tenía el túnel Cloudflare de la cuenta estebanalcocer.cloud/ehas.uk corriendo (ver Túneles de Cloudflare), así que sumar un hostname nuevo no costó infraestructura adicional.

Publicación en el apex de ehas.uk, no en un subdominio

Corre en 127.0.0.1:8083, con un hostname: ehas.uk más en el ingress del mismo túnel vm-playground (config-estebanalcocer.yml) que ya sirve dbhub.estebanalcocer.cloud, nextcloud.ehas.uk, office.ehas.uk y uptime.ehas.uk.

Se probó explícitamente que un túnel de Cloudflare sí puede servir el apex de una zona (ehas.uk sin ningún subdominio) — no es una limitación real de la plataforma. Un primer intento de verificación pareció mostrar lo contrario: curl --resolve ehas.uk:443:1.1.1.1 devolvía el error de Cloudflare 1034 (“CNAME Cross-User Banned”), que sugería un bloqueo al CNAME de *.cfargotunnel.com en la raíz de la zona. Ese resultado era inválido: el --resolve apuntaba a 1.1.1.1 (el resolver DNS de Cloudflare, no una IP del edge que sirve el sitio) en vez de a la IP real devuelta por dig @1.1.1.1 ehas.uk A. Repitiendo la prueba contra la IP correcta, el apex respondió con normalidad (petición llegó hasta el origen). Queda como referencia para no repetir el mismo diagnóstico erróneo: al probar un hostname proxied por Cloudflare con curl --resolve, la IP tiene que salir de una consulta A/AAAA real, nunca ser la IP del resolver usado para la consulta.

Se pasó primero por un subdominio de respaldo (asd.ehas.uk) mientras se investigaba el error, y se desmanteló (CNAME, ingress, Access Application) una vez confirmado que el apex funcionaba — sin rastro actual en DNS ni en el ingress.

Cloudflare Access delante, con la policy reusable existente

A diferencia de DBHub e Infisical (sin Access, por tener su propia auth), Homepage no trae ningún login propio — es un dashboard de enlaces, así que Access es la única barrera. Usa la misma policy reusable que hub/sr250 ssh/wiki (070a3c92-5aa8-4bb3-8b1f-f250ffe1526e, “google project-vm-personal”: solo ehalsou@gmail.com vía Google) — ver Cloudflare Access. Verificado sin sesión: https://ehas.uk redirige a estebanalcocer.cloudflareaccess.com/cdn-cgi/access/login/....

Gotcha: HOMEPAGE_ALLOWED_HOSTS

gethomepage valida el header Host de la petición contra una lista blanca (Host validation failed si no coincide) — mismo tipo de protección anti DNS-rebinding que --allowed-hosts en DBHub. Configurado vía .env del stack:

HOMEPAGE_ALLOWED_HOSTS=ehas.uk,127.0.0.1:8083,localhost:8083

Contenido del dashboard

services.yaml agrupa por proyecto (Personal Hub, Trivasa, Conkafecito), con un enlace por cada hostname público documentado en el resto de la wiki. Los dos servicios de conkafecito-observability (backend/TUI) no tienen túnel — se enlazan por la IP de NetBird de vm-playground (100.71.230.199:8090/:8091), consistente con que ese stack está pensado para la LAN de Conkafecito, no para internet público.

Auditoría 2026-08-26: se armó la primera versión con superset.frento.com.mx y explore.frento.com.mx (Hub Streamlit) incluidos, sin verificar si seguían vivos — ambos resultaron decomisionados (superset. desde 2026-08-09, explore. confirmado por Esteban el mismo día de esta auditoría, ver ctunlinux) y se quitaron de services.yaml. Lección para el próximo enlace que se agregue acá: un hostname documentado como status: active en la wiki no garantiza que siga vivo — conviene un curl -I rápido antes de sumarlo, sobre todo en páginas que no se tocan seguido.

Véase también

Vista Gráfica

Retroenlaces