Proxmox - Instalación de Open WebUI

Hasta ahora, la forma principal de comunicarnos con Hermes Agent era a través de Telegram. Este sistema funciona muy bien para enviar instrucciones rápidas, revisar respuestas desde el móvil o interactuar con Hermes de una forma cómoda y sencilla. Sin embargo, cuando empezamos a trabajar con mensajes largos, análisis técnicos, bloques de código, logs o instrucciones complejas, Telegram se queda un poco corto.

Ahí es donde entra Open WebUI.

1. Introducción

Open WebUI nos permite disponer de una interfaz web muy parecida a ChatGPT, accesible desde el navegador, pero conectada directamente a nuestro propio Hermes Agent instalado en un servidor Ubuntu. De esta forma podemos escribir mensajes más largos, revisar mejor las respuestas, mantener conversaciones más cómodas y trabajar desde una pantalla amplia sin depender únicamente del chat de Telegram.

La idea no es sustituir Telegram, sino añadir un segundo canal más cómodo para trabajar desde el ordenador. Telegram seguirá siendo útil como canal secundario, especialmente para consultas rápidas o uso desde el móvil, mientras que Open WebUI será la interfaz principal cuando queramos trabajar con Hermes de forma más ordenada.

En esta instalación vamos a montar Open WebUI en un Ubuntu Server dentro de Proxmox, sin usar Docker, utilizando una instalación nativa con uv. Open WebUI quedará escuchando en la red local en el puerto 3000, mientras que Hermes Agent expondrá su API solo de forma local en 127.0.0.1:8642. Esto es importante desde el punto de vista de seguridad, porque Hermes no quedará accesible directamente desde otros equipos de la red.

Nota: uv se refiere a uv de Astral, una herramienta moderna para gestionar paquetes, entornos y ejecución de aplicaciones Python.

La arquitectura final será sencilla:

El objetivo es conseguir una instalación práctica, segura y fácil de mantener: Open WebUI accesible desde la red local, Hermes protegido en localhost, servicios configurados para arrancar automáticamente y un firewall básico que limite el acceso a lo necesario.

2. Entorno utilizado

Antes de instalar Open WebUI conviene dejar claro el entorno sobre el que vamos a trabajar. En mi caso, la instalación se realiza sobre una máquina virtual creada en Proxmox, con Ubuntu Server como sistema operativo y Hermes Agent ya instalado previamente.

La idea no es instalar Hermes desde cero, sino añadir una interfaz web adicional para poder hablar con él desde el navegador. Por tanto, partimos de esta situación:

Open WebUI se instalará directamente en Ubuntu Server, sin Docker, usando uv. El acceso será únicamente desde la red local, por ejemplo:

http://IP_DEL_SERVIDOR:3000

En esta guía iremos comprobando todo paso a paso para evitar errores: primero el sistema, después Hermes, luego Open WebUI, y finalmente el arranque automático y la seguridad básica.

Paso 2.1 — Comprobar versión de Ubuntu

Este comando sirve para confirmar qué versión de Ubuntu Server tenemos instalada en la VM:

• lsb_release -a

Description:    Ubuntu 24.04.4 LTS
Codename:       noble

Paso 2.2 — Comprobar versión de Python

Ahora vamos a comprobar qué versión de Python tiene instalada el sistema.

Esto es importante porque Open WebUI lo vamos a ejecutar con uv, y uv se encargará de preparar el entorno necesario, pero conviene saber de qué parte el servidor.

• python3 --version

Python 3.12.3

Aunque Open WebUI lo ejecutaremos con uv, esta comprobación nos sirve para confirmar que el sistema tiene Python instalado correctamente y que estamos partiendo de una instalación moderna de Ubuntu.

Paso 2.3 — Comprobar que curl está instalado

Ahora vamos a comprobar si el servidor tiene disponible curl.

curl nos hará falta para dos cosas:

1. Descargar uv
2. Probar la API local de Hermes con una petición HTTP

• curl --version

curl 8.5.0

Con esto ya tenemos confirmadas tres cosas básicas del entorno:

• Ubuntu Server 24.04.4 LTS
• Python 3.12.3
• curl instalado

Paso 2.4 — Comprobar la IP local del servidor

Ahora vamos a comprobar qué IP tiene esta VM dentro de la red local.

Esto es importante porque será la dirección desde la que accederemos a Open WebUI desde el navegador, por ejemplo:

http://IP_DEL_SERVIDOR:3000

• ip -4 addr

IP local del servidor: 192.168.1.22
Interfaz de red: ens18
Red local: 192.168.1.0/24

Esto significa que, cuando Open WebUI esté instalado, accederemos desde el navegador con:

http://192.168.1.22:3000

También nos servirá más adelante para configurar el firewall y permitir el acceso solo desde la red local 192.168.1.0/24.

Paso 2.5 — Comprobar el estado del firewall

Ahora vamos a ver si ufw, el firewall de Ubuntu, está activo o no.

Esto es importante porque más adelante abriremos solo el puerto necesario para Open WebUI y dejaremos protegido el puerto local de Hermes.

• sudo ufw status

Firewall UFW: activo
SSH permitido solo desde la red local 192.168.1.0/24
Servicios Samba permitidos desde la red local
Loopback permitido

Perfecto. El firewall ya está activo y bastante bien protegido. Esto es incluso mejor que partir de un firewall desactivado. Más adelante solo añadiremos una regla nueva para permitir Open WebUI en el puerto 3000 desde la LAN.

3. Arquitectura final

La arquitectura que vamos a montar será esta:

La idea de seguridad es importante:

• Open WebUI sí será accesible desde la red local.
• Hermes API no será accesible directamente desde la red local.
• Open WebUI hablará con Hermes usando localhost.

Así, desde otro equipo de la red local podremos abrir:

http://192.168.1.22:3000

pero no deberíamos poder acceder directamente a:

http://192.168.1.22:8642

Hermes quedará protegido escuchando solo en:

127.0.0.1:8642

4. Activar API local de Hermes

Antes de instalar Open WebUI tenemos que comprobar si Hermes ya tiene activa su API local.

Esta API es la que permitirá que Open WebUI hable con Hermes usando una URL compatible con OpenAI:

http://127.0.0.1:8642/v1

Paso 4.1 — Comprobar si Hermes ya escucha en el puerto 8642

Este comando revisa si hay algún proceso escuchando en el puerto 8642, que es el puerto que usaremos para la API local de Hermes:

• sudo ss -ltnp | grep 8642

Sin salida

Si este comando no muestra ninguna línea, significa que Hermes Gateway está funcionando, pero el API Server local todavía no está activo. Open WebUI necesita esa API para poder comunicarse con Hermes.

Ahora vamos a localizar la carpeta de configuración de Hermes.

Paso 4.2 — Comprobar carpeta de Hermes

Este comando sirve para ver si existe la carpeta oculta .hermes dentro del usuario actual. Ahí suele estar la configuración de Hermes, incluido el fichero .env.

• ls -la /home/$USER/.hermes

Hermes guarda su configuración principal en:

/home/USUARIO/.hermes

y que el fichero que vamos a modificar es:

/home/USUARIO/.hermes/.env

Paso 4.3 — Comprobar si el .env ya tiene variables del API Server

Este comando busca si ya existen líneas relacionadas con API_SERVER dentro del fichero .env.

Sirve para saber si la API local de Hermes ya está configurada o si tenemos que añadirla desde cero.

• grep -n "API_SERVER" /home/$USER/.hermes/.env

Sin salida

No existe todavía ninguna variable API_SERVER en ~/.hermes/.env

Eso significa que tenemos que añadir manualmente la configuración necesaria para activar la API local de Hermes.

Paso 4.4 — Hacer copia de seguridad del fichero .env

Antes de modificar el fichero .env, vamos a crear una copia de seguridad.

Este comando copia el fichero actual y le añade la fecha y hora al nombre. Así, si nos equivocamos editando, podremos recuperar la versión anterior.

• cp /home/$USER/.hermes/.env /home/$USER/.hermes/.env.bak.$(date +%Y%m%d_%H%M%S)

Sin salida

Antes de modificar el fichero .env de Hermes, hacemos una copia con fecha y hora para poder recuperar la configuración anterior si cometemos algún error.

Paso 4.5 — Generar una clave para la API local de Hermes

Ahora vamos a generar una clave secreta para proteger la API local de Hermes.

Esta clave será la que Open WebUI usará después para conectarse a Hermes. Aunque Hermes va a escuchar solo en 127.0.0.1, es buena práctica proteger igualmente la API con una clave.

• openssl rand -hex 32

Te devolverá una cadena larga de letras y números. Guárdala porque la utilizaremos más adelante.

Paso 4.6 — Editar el fichero .env de Hermes

Este comando abre el fichero de configuración de Hermes con el editor nano.

Dentro añadiremos al final del fichero estas variables:

API_SERVER_ENABLED=true
API_SERVER_KEY=TU_CLAVE_GENERADA
API_SERVER_HOST=127.0.0.1
API_SERVER_PORT=8642

La parte importante es:

API_SERVER_HOST=127.0.0.1

Eso hace que la API de Hermes solo escuche dentro del propio servidor, no desde la red local.

• nano /home/$USER/.hermes/.env

Cuando se abra el fichero, baja al final y añade esas cuatro líneas, sustituyendo

TU_CLAVE_GENERADA 

por la clave que acabas de generar.

Guarda con 

• Ctrl + O 
• Enter 
• Ctrl + X

Editamos ~/.hermes/.env y añadimos las variables necesarias para activar el API Server local de Hermes.

Ahora tenemos que reiniciar Hermes para que lea las nuevas variables del .env.

Paso 4.7 — Reiniciar Hermes Gateway

Este comando reinicia el servicio de Hermes Gateway del usuario actual.

Lo hacemos porque Hermes ya estaba en ejecución, y los cambios del fichero .env no se aplican hasta que el proceso se reinicia.

• systemctl --user restart hermes-gateway

Sin salida

Paso 4.8 — Comprobar si la API local de Hermes ya está activa

Ahora vamos a comprobar si Hermes ya está escuchando en el puerto 8642.

Este comando muestra los puertos TCP en escucha y filtra por 8642:

• sudo ss -ltnp | grep 8642

LISTEN 0 128 127.0.0.1:8642 0.0.0.0:* users:(("python",pid=1307,fd=21))

Hermes ya tiene activa la API local en el puerto 8642.

Lo importante es que aparece:

127.0.0.1:8642

Esto significa que la API solo escucha dentro del propio servidor y no queda expuesta directamente a la red local.

Hasta aquí, Hermes ya está preparado para que Open WebUI pueda conectarse a él usando:

http://127.0.0.1:8642/v1

Paso 4.9 — Probar la API local de Hermes

Ahora vamos a hacer una prueba real contra la API de Hermes.

Este comando envía una petición a Hermes y le pide que responda solo con OK.

Tienes que sustituir:

TU_CLAVE_API_HERMES

por la clave que has puesto en el fichero .env en esta línea:

API_SERVER_KEY=...

curl http://127.0.0.1:8642/v1/chat/completions \
  -H "Authorization: Bearer TU_CLAVE_API_HERMES" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "hermes-agent",
    "messages": [
      {"role": "user", "content": "Responde solo con OK"}
    ]
  }'

La prueba devuelve una respuesta JSON donde Hermes responde:

"content": "OK"

Esto confirma que:

• Hermes API Server está activo.
• La clave API funciona.
• El modelo hermes-agent responde correctamente.
• Open WebUI podrá conectarse a Hermes usando http://127.0.0.1:8642/v1

5. Instalar uv

Ahora vamos a instalar uv.

uv es la herramienta que vamos a usar para ejecutar Open WebUI sin Docker. Nos permite lanzar Open WebUI con uvx y preparar el entorno necesario sin tener que crear manualmente un entorno virtual de Python.

Nota: uvx es el ejecutor de comandos incluido en uv. Sirve para ejecutar una herramienta Python sin instalarla manualmente de forma permanente en tu sistema.

Paso 5.1 — Instalar uv

Este comando descarga e instala uv en el usuario actual:

• curl -LsSf https://astral.sh/uv/install.sh | sh

El instalador descarga uv y uvx dentro de ~/.local/bin. uv será la herramienta principal, y uvx nos permitirá ejecutar Open WebUI sin instalarlo manualmente como paquete del sistema.

Paso 5.2 — Recargar el entorno de la terminal

Después de instalar uv, recargamos la configuración de la terminal para que el sistema reconozca los nuevos comandos uv y uvx.

• source ~/.bashrc

Sin salida

Después de instalar uv, recargamos ~/.bashrc para que la terminal encuentre los nuevos comandos uv y uvx sin tener que cerrar y abrir la sesión SSH.

Paso 5.3 — Comprobar que uv funciona

Ahora vamos a comprobar que uv está instalado correctamente.

Este comando muestra la versión instalada de uv:

• uv --version

uv 0.11.17 (x86_64-unknown-linux-gnu)

uv y uvx están correctamente instalados. A partir de este punto ya podemos usar uvx para lanzar Open WebUI sin Docker.

6. Instalar Open WebUI sin Docker

Ahora vamos a preparar Open WebUI. En esta guía no lo instalaremos con Docker. Lo ejecutaremos usando uvx, definiendo algunas variables importantes:

DATA_DIR
WEBUI_SECRET_KEY
WEBUI_AUTH
ENABLE_SIGNUP
OPENAI_API_BASE_URL
OPENAI_API_KEY
OLLAMA_BASE_URL

La más importante para los datos es:

DATA_DIR

Ahí se guardará la configuración, usuarios, conversaciones y base de datos de Open WebUI.

Usaremos esta ruta:

/home/USUARIO/open-webui-data

Paso 6.1 — Crear carpeta de datos de Open WebUI

Este comando crea la carpeta donde Open WebUI guardará sus datos persistentes:

• mkdir -p /home/$USER/open-webui-data

Sin salida

Creamos una carpeta persistente para Open WebUI. En ella se guardarán usuarios, configuración, conversaciones y base de datos. Si no definimos una carpeta clara, podríamos acabar con datos en rutas temporales o menos fáciles de mantener.

Paso 6.2 — Comprobar que la carpeta existe

Ahora vamos a comprobar que la carpeta se ha creado y que pertenece al usuario actual.

• ls -ld /home/$USER/open-webui-data

drwxrwxr-x 2 USUARIO USUARIO 4096 may 29 19:49 /home/USUARIO/open-webui-data

La carpeta de datos persistentes de Open WebUI se ha creado correctamente y pertenece al usuario.

Paso 6.3 — Generar clave secreta para Open WebUI

Ahora vamos a generar una clave secreta propia de Open WebUI.

Esta clave no es la misma que la clave de Hermes. Open WebUI la usa internamente para proteger sesiones y datos de autenticación.

• openssl rand -hex 32

Guardamos la clave que la usaremos más adelante.

Paso 6.4 — Primer arranque manual de Open WebUI

Ahora vamos a arrancar Open WebUI manualmente, todavía sin crear el servicio systemd.

Este primer arranque sirve para comprobar que:

• Open WebUI descarga correctamente sus dependencias.
• La interfaz web carga en el navegador.
• Open WebUI puede conectarse a Hermes.

Ejecuta el siguiente comando, sustituyendo:

CLAVE_SECRETA_OPENWEBUI

por la clave que acabas de generar, y:

CLAVE_API_HERMES

por la clave que pusiste en API_SERVER_KEY dentro de ~/.hermes/.env.

DATA_DIR=/home/$USER/open-webui-data \
WEBUI_SECRET_KEY=CLAVE_SECRETA_OPENWEBUI \
WEBUI_AUTH=True \
ENABLE_SIGNUP=True \
OPENAI_API_BASE_URL=http://127.0.0.1:8642/v1 \
OPENAI_API_KEY=CLAVE_API_HERMES \
OLLAMA_BASE_URL= \
uvx --python 3.11 open-webui@latest serve --host 0.0.0.0 --port 3000

Este comando puede tardar bastante la primera vez porque descarga Open WebUI y prepara el entorno.

Si se corta la sesión ssh porque ha expirado el tiempo, abre una nueva terminal.

Paso 6.5 — Comprobar si Open WebUI está escuchando en el puerto 3000

Este comando revisa si hay algún proceso escuchando en el puerto 3000, que es el puerto donde intentamos arrancar Open WebUI:

• sudo ss -ltnp | grep 3000

LISTEN 0      2048  0.0.0.0:3000  0.0.0.0:*    users:(("python",pid=1575,fd=33))

Aunque la terminal SSH se haya desconectado, comprobamos que Open WebUI sigue activo revisando si hay algún proceso escuchando en el puerto 3000.

Paso 6.6 — Probar Open WebUI desde el servidor

Este comando hace una petición HTTP local a Open WebUI para comprobar si la web responde:

• curl -I http://127.0.0.1:3000

HTTP/1.1 200 OK
server: uvicorn

Open WebUI ya está levantado en el servidor y responde localmente en el puerto 3000.

Ahora hay un detalle importante: en esta VM el firewall ya estaba activo, y todavía no hemos permitido el puerto 3000 desde la red local. Por eso, aunque Open WebUI responda dentro del servidor, puede que todavía no cargue desde tu PC.

Vamos a añadir la regla del firewall para permitir Open WebUI desde la LAN.

Paso 6.7 — Permitir acceso a Open WebUI desde la red local

Este comando permite que los equipos de la red local 192.168.1.0/24 puedan acceder al puerto 3000, que es donde escucha Open WebUI:

• sudo ufw allow from 192.168.1.0/24 to any port 3000 proto tcp

Rule added

Como el firewall ya estaba activo, añadimos una regla para permitir que los equipos de la red local puedan acceder a Open WebUI en el puerto 3000.

Ahora vamos a comprobar que la regla ha quedado registrada.

Paso 6.8 — Comprobar estado del firewall

Este comando muestra las reglas actuales de UFW:

• sudo ufw status

Status: active
......
3000/tcp                   ALLOW       192.168.1.0/24
......

El firewall ya permite el acceso a Open WebUI desde cualquier equipo de la red local 192.168.1.0/24, pero mantiene bloqueado el acceso desde fuera de esa red.

Ahora ya deberías poder entrar desde el navegador de tu PC.

Paso 6.9 — Acceder a Open WebUI desde el navegador

Abre en tu navegador:

http://192.168.1.22:3000

Debería aparecer la pantalla inicial de Open WebUI.

Pulsa Empezar y crea el primer usuario administrador.

Ahora vamos a comprobar que Open WebUI realmente puede hablar con Hermes.

Paso 6.10 — Probar Hermes desde Open WebUI

En la caja de chat de Open WebUI escribe:

Responde solo con OK

Esta prueba nos sirve para comprobar toda la cadena:

Navegador
  → Open WebUI
  → API local de Hermes
  → Hermes Agent

Al enviar “Responde solo con OK” desde Open WebUI, Hermes responde correctamente. Esto confirma que la cadena completa funciona:

Navegador → Open WebUI → API local de Hermes → Hermes Agent

7. Crear servicio systemd

Hasta ahora Open WebUI está funcionando porque lo hemos lanzado manualmente con uvx.

El problema de este método es que no es la forma más cómoda ni más robusta para usarlo a diario. Lo ideal es crear un servicio systemd para que Open WebUI:

• arranque automáticamente con Ubuntu Server
• se reinicie si falla
• no dependa de una terminal SSH abierta
• se pueda gestionar con systemctl

Antes de crear el servicio necesitamos guardar las variables de configuración en un fichero .env.

Paso 7.1 — Crear fichero de configuración de Open WebUI

Este comando abre un nuevo fichero donde guardaremos la configuración de Open WebUI:

• nano /home/$USER/open-webui.env

Dentro tendrás que pegar este contenido, sustituyendo las dos claves por las reales:

DATA_DIR=/home/madiazg/open-webui-data
WEBUI_SECRET_KEY=CLAVE_SECRETA_OPENWEBUI
WEBUI_AUTH=True
ENABLE_SIGNUP=True
OPENAI_API_BASE_URL=http://127.0.0.1:8642/v1
OPENAI_API_KEY=CLAVE_API_HERMES
OLLAMA_BASE_URL=

Donde:

CLAVE_SECRETA_OPENWEBUI = la clave que generaste para Open WebUI
CLAVE_API_HERMES = la clave API de Hermes que pusiste en ~/.hermes/.env

Guarda con:

• Ctrl + O
• Enter
• Ctrl + X

Creamos un fichero open-webui.env para guardar las variables necesarias de Open WebUI en un lugar separado y más fácil de mantener que un comando largo.

Ahora vamos a proteger ese fichero, porque contiene claves.

Paso 7.2 — Proteger el fichero de configuración

Este comando cambia los permisos del fichero para que solo tu usuario pueda leerlo y modificarlo:

• chmod 600 /home/$USER/open-webui.env

Sin salida

Es importante porque dentro están:

WEBUI_SECRET_KEY
OPENAI_API_KEY

Protegemos el fichero de configuración porque contiene claves internas de Open WebUI y la clave que se usará para conectar con Hermes.

Paso 7.3 — Crear el servicio systemd de Open WebUI

Ahora vamos a crear el servicio de systemd.

Este servicio permitirá gestionar Open WebUI con comandos como:

• start
• stop
• restart
• status

y además hará que Open WebUI pueda arrancar automáticamente con Ubuntu.

• sudo nano /etc/systemd/system/open-webui.service

Dentro pega este contenido (no olvides sustituir USUSARO por tu nombre de usuario):

[Unit]
Description=Open WebUI for Hermes
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=USUARIO
Group=USUARIO
WorkingDirectory=/home/USUARIO
EnvironmentFile=/home/USUARIO/open-webui.env
ExecStart=/home/USUARIO/.local/bin/uvx --python 3.11 open-webui@latest serve --host 0.0.0.0 --port 3000
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Guarda con:

• Ctrl + O
• Enter
• Ctrl + X

Creamos el fichero /etc/systemd/system/open-webui.service para que Open WebUI pueda ejecutarse como servicio del sistema. En este servicio indicamos el usuario, la carpeta de trabajo, el fichero de variables y el comando uvx que arranca Open WebUI en el puerto 3000.

Ahora systemd todavía no sabe que acabamos de crear ese servicio. Hay que recargar su configuración.

Paso 7.4 — Recargar systemd

Este comando hace que systemd vuelva a leer los ficheros de servicios disponibles, incluyendo el nuevo open-webui.service que acabamos de crear:

• sudo systemctl daemon-reload

Sin salida

Paso 7.5 — Habilitar Open WebUI para que arranque con Ubuntu

Ahora vamos a habilitar el servicio.

Este comando no arranca todavía Open WebUI, solo le indica a Ubuntu que debe iniciarlo automáticamente cada vez que arranque el sistema:

• sudo systemctl enable open-webui

Created symlink /etc/systemd/system/multi-user.target.wants/open-webui.service → /etc/systemd/system/open-webui.service.

Al habilitar el servicio, systemd crea un enlace dentro de multi-user.target.wants. Esto significa que Open WebUI se iniciará automáticamente cuando arranque Ubuntu Server.

Ahora todavía tenemos un detalle importante: Open WebUI sigue funcionando desde el arranque manual anterior. Antes de arrancarlo como servicio, hay que liberar el puerto 3000 para evitar que el servicio falle porque el puerto ya está ocupado.

Paso 7.6 — Parar el Open WebUI arrancado manualmente

Este comando detiene el proceso Python que está escuchando en el puerto 3000.

• sudo fuser -k 3000/tcp

Sin salida

Paso 7.7 — Comprobar que el puerto 3000 está libre

Este comando comprueba si todavía hay algún proceso escuchando en el puerto 3000:

sudo ss -ltnp | grep 3000

Sin salida

Como no muestra nada, significa que el Open WebUI manual se ha parado correctamente y ya podemos arrancarlo como servicio.

Paso 7.8 — Arrancar Open WebUI como servicio

Este comando inicia Open WebUI usando el servicio systemd que acabamos de crear:

• sudo systemctl start open-webui

Sin salida

Ahora vamos a comprobar el estado real del servicio.

Paso 7.9 — Comprobar estado del servicio Open WebUI

Este comando muestra si el servicio está activo, si ha fallado o si sigue arrancando:

• sudo systemctl status open-webui

Nota: Si se abre una pantalla larga, puedes salir pulsando q

Perfecto. El servicio está funcionando correctamente.

En la captura se ve:

Loaded: loaded ... enabled
Active: active (running)
Main PID: 2131

Eso confirma que:

• Open WebUI ya está funcionando como servicio systemd
• El servicio está habilitado para arrancar con Ubuntu
• El proceso está activo

Paso 7.10 — Comprobar que Open WebUI escucha en el puerto 3000

Este comando verifica que el servicio realmente está escuchando en el puerto 3000:

• sudo ss -ltnp | grep 3000

LISTEN 0   2048   0.0.0.0:3000  0.0.0.0:*    users:(("python",pid=2178,fd=28))

Esa salida confirma que Open WebUI está escuchando correctamente:

0.0.0.0:3000

8. Seguridad básica

Ahora vamos a revisar y cerrar algunos puntos de seguridad.

Ya tenemos varias cosas bien configuradas:

• Open WebUI tiene login activado
• El firewall está activo
• El puerto 3000 está permitido solo desde la LAN
• Hermes escucha solo en 127.0.0.1:8642

Pero todavía nos queda un punto importante: cerrar el registro de nuevos usuarios en Open WebUI.

Durante la primera instalación dejamos:

ENABLE_SIGNUP=True

para poder crear el primer usuario administrador. Una vez creado, conviene cambiarlo a:

ENABLE_SIGNUP=False

Así evitamos que otra persona de la red local pueda registrarse en Open WebUI.

Paso 8.1 — Cerrar el registro de usuarios

Este comando abre el fichero de configuración de Open WebUI:

• nano /home/$USER/open-webui.env

Dentro busca esta línea:

ENABLE_SIGNUP=True

y cámbiala por:

ENABLE_SIGNUP=False

Guarda con:

• Ctrl + O
• Enter
• Ctrl + X

Ahora hay que reiniciar Open WebUI para que lea el cambio.

Paso 8.2 — Reiniciar Open WebUI

Este comando reinicia el servicio de Open WebUI para aplicar el cambio de configuración:

• sudo systemctl restart open-webui

Sin salida

Paso 8.3 — Comprobar que Open WebUI sigue activo

Este comando comprueba que el servicio sigue funcionando después del reinicio:

• sudo systemctl status open-webui

Nota: Si se abre una pantalla larga, sal con q.

El servicio sigue funcionando correctamente después de cerrar el registro. En la captura se ve:

Loaded: loaded ... enabled
Active: active (running)
Main PID: 2282

Paso 8.4 — Comprobar que Open WebUI sigue escuchando en el puerto 3000

Este comando confirma que Open WebUI continúa escuchando en el puerto 3000 después del reinicio:

• sudo ss -ltnp | grep 3000

LISTEN 0  2048   0.0.0.0:3000  0.0.0.0:*    users:(("python",pid=2309,fd=28)) 

Perfecto. Open WebUI sigue escuchando correctamente en el puerto 3000:

0.0.0.0:3000

Ahora vamos a comprobar la parte de Hermes dentro del punto de seguridad.

Paso 8.5 — Comprobar que Hermes escucha solo en localhost

Este comando comprueba si la API de Hermes sigue activa en el puerto 8642:

• sudo ss -ltnp | grep 8642

LISTEN 0   128 127.0.0.1:8642  0.0.0.0:*    users:(("python",pid=1307,fd=21))

Esta salida confirma que Hermes está configurado de forma segura:

127.0.0.1:8642

Aunque Hermes ya escucha solo en localhost, vamos a añadir una regla defensiva al firewall para bloquear el puerto 8642 desde fuera.

Paso 8.6 — Bloquear el puerto 8642 en UFW

Este comando añade una regla explícita para denegar conexiones entrantes al puerto 8642:

• sudo ufw deny 8642/tcp

Rule added
Rule added (v6)

Perfecto. El puerto 8642 ha quedado bloqueado explícitamente en UFW.

Ahora vamos a comprobar el estado final del firewall.

Paso 8.7 — Revisar reglas del firewall

Este comando muestra las reglas actuales de UFW:

• sudo ufw status

Status: active
....
3000/tcp                   ALLOW       192.168.1.0/24
8642/tcp                   DENY        Anywhere
.....

Esto significa:

• Open WebUI:
•   accesible desde la red local
• Hermes API:
•   no accesible directamente desde la red local
•   solo accesible desde el propio servidor mediante 127.0.0.1

9. Comprobación tras reinicio

Ahora toca hacer la prueba final: reiniciar la VM y comprobar que todo vuelve a arrancar automáticamente.

La idea es validar que:

• Hermes Gateway arranca solo
• Hermes API vuelve a escuchar en 127.0.0.1:8642
• Open WebUI arranca solo como servicio
• Open WebUI vuelve a escuchar en 0.0.0.0:3000
• La web responde desde el navegador
• Open WebUI sigue pudiendo hablar con Hermes

Paso 9.1 — Reiniciar la VM

Este comando reinicia Ubuntu Server:

• sudo reboot

La conexión SSH se cortará, es normal.Espera aproximadamente 1 o 2 minutos, vuelve a conectarte por SSH.

Paso 9.2 — Comprobar que Open WebUI ha arrancado tras el reinicio

Este comando muestra el estado del servicio de Open WebUI después de reiniciar la VM:

• sudo systemctl status open-webui

Si se abre una pantalla larga, sal con q.

El resultado muestra:

Loaded: loaded ... enabled
Active: active (running)

Esto confirma que Open WebUI se ha iniciado automáticamente con Ubuntu Server.

También se ve que está consumiendo bastante memoria:

Memory: 1.6G

Paso 9.3 — Comprobar que Open WebUI escucha en el puerto 3000

Ahora vamos a comprobar que el servicio está escuchando en el puerto correcto después del reinicio.

Este comando revisa si hay algún proceso escuchando en el puerto 3000:

• sudo ss -ltnp | grep 3000

LISTEN 0  2048  0.0.0.0:3000    0.0.0.0:*    users:(("python",pid=988,fd=28))  

Open WebUI está escuchando correctamente tras el reinicio:

0.0.0.0:3000

Paso 9.4 — Comprobar que Hermes API ha arrancado tras el reinicio

Este comando comprueba si Hermes vuelve a escuchar en el puerto 8642 después de reiniciar:

• sudo ss -ltnp | grep 8642

LISTEN 0  128   127.0.0.1:8642   0.0.0.0:*    users:(("python",pid=896,fd=21))  

Hermes también ha arrancado correctamente tras el reinicio:

127.0.0.1:8642

Con esto ya tenemos confirmados los dos puertos importantes:

• Open WebUI: 0.0.0.0:3000
• Hermes API: 127.0.0.1:8642

Ahora queda la última comprobación funcional desde el navegador.

Paso 9.5 — Probar la conversación desde Open WebUI tras el reinicio

Abre en el navegador:

http://192.168.1.22:3000

Inicia sesión en Open WebUI si te lo pide y escribe en el chat:

Responde solo con OK

Esta prueba confirma la cadena completa después del reinicio:

• Navegador
•   → Open WebUI arrancado como servicio
•   → Hermes API arrancada automáticamente
•   → Hermes Agent

10. Comandos útiles de mantenimiento

Para terminar el artículo, conviene dejar una pequeña chuleta de comandos útiles. No hace falta ejecutarlos todos ahora; sirven para consultar, reiniciar o diagnosticar la instalación en el futuro.

Comprobar el estado de Open WebUI:
sudo systemctl status open-webui

Comprobar estado de Hermes Gateway:
systemctl --user status hermes-gateway

Reiniciar Open WebUI:
sudo systemctl restart open-webui

Reiniciar Hermes Gateway:
systemctl --user restart hermes-gateway

Parar Open WebUI:
sudo systemctl stop open-webui

Parar Hermes Gateway:
systemctl --user stop hermes-gateway

Arrancar Open WebUI:
sudo systemctl start open-webui

Arrancar Hermes Gateway:
systemctl --user start hermes-gateway

Comprobar si Open WebUI escucha en el puerto 3000:
sudo ss -ltnp | grep 3000

Comprobar si Hermes API escucha en el puerto 8642:
sudo ss -ltnp | grep 8642

Ver logs recientes de Open WebUI:
journalctl -u open-webui -n 80 --no-pager

Ver logs en directo de Open WebUI:
journalctl -u open-webui -f

Ver logs recientes de Hermes Gateway:
journalctl --user -u hermes-gateway -n 80 --no-pager

Ver logs en directo de Hermes Gateway:
journalctl --user -u hermes-gateway -f

Ver estado del firewall UFW:
sudo ufw status

Ver estado detallado del firewall UFW:
sudo ufw status verbose

Editar configuración de Open WebUI:
nano /home/$USER/open-webui.env

Editar configuración de Hermes:
nano /home/$USER/.hermes/.env

Reiniciar Open WebUI después de cambiar su configuración:
sudo systemctl restart open-webui

Reiniciar Hermes Gateway después de cambiar su configuración:
systemctl --user restart hermes-gateway

Comprobar que Hermes responde directamente por API local:
curl http://127.0.0.1:8642/v1/chat/completions \

  -H "Authorization: Bearer TU_CLAVE_API_HERMES" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "hermes-agent",
    "messages": [
      {"role": "user", "content": "Responde solo con OK"}
    ]
  }'

Comprobar si el servicio de usuario puede arrancar sin iniciar sesión:
loginctl show-user $USER | grep Linger

Activar linger para el usuario actual si fuera necesario:
sudo loginctl enable-linger $USER

Reiniciar la VM:
sudo reboot

Conclusiones finales

Con esta instalación hemos conseguido usar Hermes Agent desde una interfaz web tipo ChatGPT, mucho más cómoda para trabajar con conversaciones largas, código, logs o análisis técnicos.

Open WebUI queda como interfaz principal desde el navegador, mientras que Telegram puede mantenerse como canal secundario para consultas rápidas o uso desde el móvil.

La arquitectura final es sencilla: Open WebUI actúa como puerta de entrada, y Hermes permanece protegido, accesible solo desde el propio servidor. Esto permite trabajar cómodamente sin exponer directamente la API de Hermes a la red.

También hemos dejado la instalación preparada para el uso diario: Open WebUI arranca automáticamente con Ubuntu, Hermes Gateway sigue funcionando como servicio, el registro de nuevos usuarios queda cerrado y el firewall limita el acceso a lo necesario.

Tras reiniciar la máquina virtual, ambos servicios vuelven a iniciarse correctamente y la comunicación entre Open WebUI y Hermes sigue funcionando. Esto confirma que la instalación es persistente, práctica y adecuada para un entorno local en Proxmox.

En resumen, esta configuración permite trabajar con Hermes de forma más cómoda, ordenada y segura, manteniendo Telegram como apoyo y usando Open WebUI como interfaz principal desde el ordenador.