Inventario Proxmox — fuente de verdad del estado

Última verificación: 2026-08-29 (SSH, API de Proxmox y API de Coolify desde esta máquina).

Este documento es la fuente de verdad de qué existe. Si algo aquí contradice a la realidad del host, gana el host: re-verifica y actualiza este archivo.

Para refrescarlo:

. .\.env.local.ps1
.\scripts\Get-ProxmoxInventory.ps1
.\coolify_skill\scripts\Invoke-CoolifyApi.ps1 -Path "/resources" -Raw |
    Sort-Object name | Select-Object name, uuid, fqdn

Host

Dato	Valor
IP	`192.168.0.200` (IPs verificadas en red: `192.168.3.23` / `192.168.3.15` / `192.168.0.200`)
Nodo	`thinkcentre`
Proxmox VE	`9.1.1` (`pve-manager/9.1.1/42db4a6cf33dac83`)
Kernel	`6.17.2-1-pve`
Topología	Proxmox de un solo nodo
Disco `/`	39 GB, 11 GB usados (29%)
RAM	31 GiB totales — 14 GiB en uso, 16 GiB disponibles
Swap	7.6 GiB, 303 MiB en uso

Contenedores LXC

VMID	Nombre	Estado	IPs	Notas
100	hermes	running	`192.168.3.23` / `192.168.3.15`	Secundario. Actualizado a commit `5d3c15aaa`. MiniMax-M3 y API key configuradas y verificadas con inferencia CLI en vivo. Ver caso docs/casos/hermes-minimax-m3-setup.md.
102	coolify	running	`192.168.0.200` (host bridge)	Host Docker de Coolify y de todas las apps.

No hay VMs QEMU (qm list vacío).

Docker dentro de LXC 102

Docker no se administra en el host Proxmox directamente. Todo comando va envuelto:

.\scripts\Invoke-ProxmoxSsh.ps1 -Command "pct exec 102 -- docker ps"

68 contenedores, todos running al momento de la verificación.

Los nombres de contenedor llevan el uuid de Coolify como sufijo — no son adivinables y cambian si un redeploy recrea el contenedor. Resuélvelos siempre antes de usarlos; ver §1.3 de TOOL-INDEX.md.

Núcleo de la plataforma

Contenedor	Imagen
`coolify`	`ghcr.io/coollabsio/coolify:4.3.14` (`GET /version` → `4.3.14`, verificado 2026-08-29)
`coolify-db`	`postgres:15-alpine`
`coolify-redis`	`redis:7-alpine`
`coolify-realtime`	`ghcr.io/coollabsio/coolify-realtime:1.0.17`
`coolify-sentinel`	`ghcr.io/coollabsio/sentinel:0.0.22`
`coolify-proxy`	`traefik:v3.6`
`cloudflared`	— (túnel gestionado desde el dashboard)

Recursos registrados en Coolify (29)

Del endpoint /resources. El uuid es lo que necesitas para la API y para resolver nombres de contenedor.

Recurso	uuid	FQDN
agendamax:main	`s30f7egdlkx4wyjp59o1iunc`	https://agendamax.urieljareth.org
audio-a--texto:main	`up0oaqnpd8kywjkmmihb61t0`	https://stt.urieljareth.org
baserow:main	`vngcvnhbfqboov4nln88zc73`	—
baserow-redis	`vztgldo9cap3s0oj240tokgj`	—
chatwoot	`c11xzy2tx2cdapm32f5b89vy`	—
codimd	`ag4ndg4cr1hvczkr35qlyzs8`	—
cotizador:main	`e6vie34d83iv5vw3eyzinl3s`	`…:3000` (sin dominio propio)
demospa	`2f094556a04c0dee043af215`	https://demospa.urieljareth.org
demospa-mysql	`teplxg70a97itolgwk2qkmgi`	—
e3-manager-demo	`xxoq93pnz0jta5tz5m50ylig`	—
estaci-n-de-documentos:main	`u11ug3eizk9du3p2ch556ud4`	—
evolution-go	`j0jkacsfcgypm2jmpillls01`	https://evo.urieljareth.org (API WhatsApp 0.7.2, licencia activa — ver casos/evolution-go-stack.md)
evolution-api	`q6tnsvkvrjw4g0ab532l3r1s`	https://evoapi.urieljareth.org (Node v2.3.7; integrada a Chatwoot: inbox 6=Asesoría, 10=Personal, 12=JM; INSTA desconectada — ver casos/evolution-api-chatwoot.md)
firecrawl:main	`du3iknyvy22vap767t9tnf9s`	— (registrado pero sin contenedor corriendo)
gitea-with-postgresql	`hjwh0svsoo9p5w5kj2j6b1bd`	—
grimmory	`y8cq6jmboz0b22mn61hs4tu8`	—
insta-portal	`instademo0portal0insta0demo1`	`…:4180`
n8n-with-postgres-and-worker	`jdj3y3kmz9blec7ntbxuhezi`	—
nextcloud-with-postgres	`hdcdpkm0jko3qqvn5683ercc`	—
openclaw-business	`zhaz04q8ibqp5r5hz5ibo01t`	—
openclaw (2ª instancia)	`uudgcoz5ibvyvullyzbjalai`	—
open-webui	`q13zdxusnhvdent7f44a18kc`	—
plataforma-interna	`kruadlc7fdrbh28ykrv8rdyl`	—
postgresql-database	`j6hgnvdwq9anpa9wj2ikdx0j`	—
postgresql-database	`s10bvby71tb1fpbcl4tnxzzh`	—
postgresql-database	`tflojv1iqh0ueoq7apxx4mos`	—
prompt-gallery-e3:main	`39eu76lqbejdy9vxs5iz1rws`	https://demopromptgallerye3.urieljareth.org
qdrant	`uyn0js6pqbwo8mubw5edy95f`	—
solo-leveling	`urm8m4u0jvjggmgpfxblnqwc`	—

Stack de Supabase

Corre con nombres fijos (sin sufijo uuid), fuera del patrón habitual de Coolify: supabase-db (supabase/postgres:17.6.1.136), supabase-kong, supabase-auth, supabase-rest, supabase-storage, supabase-studio, supabase-meta, supabase-imgproxy, realtime-dev.supabase-realtime. También e3-mailpit (axllent/mailpit).

Versiones que importan

App	Imagen en ejecución
Chatwoot	`chatwoot/chatwoot:v4.16.2` (app y sidekiq)
Chatwoot DB	`pgvector/pgvector:pg12`
n8n	`n8nio/n8n:2.32.7`
Baserow	`baserow/baserow:2.3.2`
OpenClaw	`coollabsio/openclaw:2026.7.1`
Evolution API	`evoapicloud/evolution-api:v2.3.7`
Gitea	`gitea/gitea:latest`
Nextcloud	`lscr.io/linuxserver/nextcloud:latest`
Grimmory	`grimmory/grimmory:nightly`
Solo Leveling	`ghcr.io/urieljarethbusiness-cpu/solo-leveling:latest`

Estado de la API de Coolify

Base pública: https://coolify.urieljareth.org/api/v1 (Bearer COOLIFY_TOKEN) · Origen: http://192.168.0.117:8000/api/v1 · Instancia: 4.3.14.

Re-verificado a fondo el 2026-08-29, con hallazgo que corrige todo lo anterior:

La API de esta instancia está COMPLETA. Su propio openapi.yaml (dentro del contenedor en /var/www/html/openapi.yaml) declara el namespace completo de /applications/* (incl. POST /applications/public, /dockerfile, /private-deploy-key, /private-github-app), /github-apps, /gitlab-apps, notificaciones, proveedores cloud (Hetzner/DigitalOcean/Vultr), MCP, etc. — y contra el origen esos endpoints responden 200 con el token de siempre.
El 404 de /applications/* que se venía documentando desde v4.1.2 NO lo produce Coolify: lo produce Cloudflare en el hostname público. Mismo token, misma ruta: https://coolify.urieljareth.org/api/v1/applications → 404; http://192.168.0.117:8000/api/v1/applications → 200. Es un bloqueo del edge (regla WAF/ruta en el dashboard) que hay que corregir allí; mientras tanto, llama a esos endpoints contra COOLIFY_API_URL_ORIGIN.
Desde v4.2 los endpoints de estado exigen POST (GET /deploy?uuid= → 405 "This endpoint has changed to a POST request." — confirmado también contra el origen; ver §10.1 de las notas). En 4.3.x se añadieron endpoints de logs (db/servicio/contenedor), settings en las respuestas de application y MCP.

Endpoint (con token válido)	Vía Cloudflare	Vía origen (LXC 102)
`/version`, `/resources`, `/servers`, `/projects`, `/teams`, `/services`, `/databases`, `/deployments`, `/security/keys`	OK	OK
`/applications` y todo su namespace	404 (Cloudflare)	OK (200)
`/github-apps`	404 (Cloudflare)	OK (200)
`/deploy` con GET	405	405 (correcto: exige POST desde v4.2)

Modelo de acceso

SSH: root con autenticación por clave. La llave operativa es keys/proxmox_ed25519 (idéntica a C:\Users\Uriel Jareth\.ssh\coolify_key; ED25519, sin passphrase) — verificada en vivo el 2026-08-29 contra el host (192.168.0.200) y el LXC 102 (192.168.0.117). La ruta …\.openclaw\workspace\proxmox_key_win citada en docs antiguos ya no existe. Es el único camino directo al host; permite ejecutar comandos en el host y en los contenedores LXC (pct exec 100, pct exec 102).
API de Proxmox: token root@pam!openclaw — único token del host (/etc/pve/priv/token.cfg), verificado 200 el 2026-08-29. Ya cargado en .env.local.ps1 (PROXMOX_API_TOKEN_ID / PROXMOX_API_TOKEN_SECRET).
API de Coolify: COOLIFY_TOKEN (v4.3.14, verificado).
API de Cloudflare: sin token — el túnel se gestiona desde el dashboard.
Los secretos viven solo en .env.local.ps1 (gitignored), en ACCESS.md (gitignored, fuente de verdad de credenciales) o en el almacén de secretos del SO. Nunca en Markdown versionado. Inventario de credenciales: ACCESS.md

⚠️ Pendiente en .env.local.ps1 (2026-08-29): solo CLOUDFLARE_API_TOKEN. El PAT de GitHub que había caducó (401); se reemplazó por la credencial viva del Administrador de credenciales de Windows. PROXMOX_API_TOKEN_ID/SECRET, COOLIFY_EMAIL/PASSWORD ya están cargados. SSH, API de Proxmox y API de Coolify verificados.

Automatizaciones instaladas en el host

Qué	Dónde	Agendado por
Guard del parche enterprise de Chatwoot	`/root/scripts/chatwoot-enterprise-guard.sh`	`/etc/cron.d/chatwoot-enterprise-guard`, `/5 * * *`
Auto-arranque tras corte de luz	unit `coolify-autostart.service`	systemd, `enabled`

Log del guard: /var/log/chatwoot-enterprise-guard.log (solo escribe cuando actúa). Estado al 2026-08-07: el plan está en enterprise y una ejecución manual del guard pasa correctamente, pero el log registra errores de lectura durante la ventana del update a v4.16.2 — ver runbooks/chatwoot-update.md.

9.6 KiB Raw Blame History