La idea es sencilla: Ollama sigue ejecutándose en local dentro del servidor Linux, pero Cloudflare crea un túnel saliente seguro que permite acceder desde fuera sin abrir puertos en el router y sin depender de una IP pública fija.

Objetivo

Queremos conseguir que un servidor Linux local con Ollama responda a peticiones externas como esta:

curl https://ollama.tonyhelper.com/api/tags

Y que internamente ese tráfico termine llegando a:

http://localhost:11434

Esto es especialmente útil cuando el servidor está detrás de un router doméstico o de operador, donde la IP pública puede cambiar y donde no siempre interesa abrir puertos hacia el exterior.

Qué necesitamos

Antes de empezar, conviene tener esto preparado:

• Un dominio gestionado en Cloudflare, en este caso tonyhelper.com.

• Un subdominio que vamos a dedicar a Ollama: ollama.tonyhelper.com.

• Un servidor Linux local con Ollama ya instalado y funcionando.

• cloudflared instalado en el servidor.

• Acceso a la cuenta de Cloudflare para autorizar la creación del túnel.

Paso 1. Comprobar que Ollama funciona en local

Antes de tocar Cloudflare, lo primero es verificar que Ollama responde correctamente dentro del servidor.

curl http://127.0.0.1:11434/api/tags

Si queremos comprobar que el modelo responde, podemos hacer una prueba sencilla:

curl http://127.0.0.1:11434/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4",
    "prompt": "Di hola en una frase",
    "stream": false
  }'

Si estas pruebas funcionan, significa que la base está bien y podemos continuar.

Paso 2. Instalar cloudflared

En Ubuntu o Debian podemos instalar cloudflared desde el repositorio oficial de Cloudflare.

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update
sudo apt install cloudflared
cloudflared version

Con esto dejamos instalado el cliente que se encargará de mantener el túnel abierto desde el servidor hacia Cloudflare.

Paso 3. Autorizar cloudflared con nuestra cuenta

El siguiente paso es autenticar el servidor contra la cuenta de Cloudflare:

cloudflared tunnel login

Este comando abre el navegador para iniciar sesión y seleccionar la zona del dominio. Al completarlo, Cloudflare guarda el certificado de cuenta en la carpeta de configuración local.

Podemos comprobarlo así:

ls -l ~/.cloudflared/cert.pem

Ese archivo es importante porque permite crear y gestionar túneles desde la línea de comandos.

Paso 4. Crear un túnel nombrado

En este caso vamos a usar un nombre claro para el túnel:

cloudflared tunnel create ollama-aiserver

Al ejecutarlo, Cloudflare genera un UUID para el túnel y un archivo JSON de credenciales dentro de ~/.cloudflared/.

Podemos verlo con:

cloudflared tunnel list
ls -l ~/.cloudflared/

Aquí aparecerá el nombre del túnel, su UUID y el archivo de credenciales correspondiente.

Paso 5. Crear el DNS del subdominio

Una vez creado el túnel, toca vincular el subdominio ollama.tu-dominio.com a ese túnel:

cloudflared tunnel route dns ollama-aiserver ollama.tu-dominio.com

Este comando crea el registro DNS necesario en Cloudflare. A partir de ese momento, ollama.tu-dominio.com quedará apuntando al túnel.

Paso 6. Crear el archivo de configuración

Ahora hay que decirle al túnel qué debe hacer cuando reciba tráfico para ese subdominio.

Creamos o editamos el archivo:

nano ~/.cloudflared/config.yml

Y añadimos este contenido, sustituyendo TU_UUID por el UUID real generado al crear el túnel:

tunnel: TU_UUID
credentials-file: /home/TU-USUARIO/.cloudflared/TU_UUID.json

ingress:
  - hostname: ollama.tu-dominio.com
    service: http://localhost:11434
    originRequest:
      httpHostHeader: localhost:11434

  - service: http_status:404

Este bloque hace algo muy concreto:

• Cuando llega tráfico para ollama.tu-dominio.com,

• Cloudflare lo envía por el túnel,

• y cloudflared lo reenvía a http://localhost:11434, que es donde escucha Ollama.

La cabecera httpHostHeader: localhost:11434 ayuda a mantener la compatibilidad esperada por Ollama en este escenario.

Paso 7. Ejecutar el túnel

Con el archivo listo, arrancamos el túnel:

cloudflared tunnel run

También podría arrancarse indicando el nombre:

cloudflared tunnel run ollama-aiserver

Si todo está correcto, el túnel quedará conectado y el subdominio empezará a funcionar como punto de acceso externo al servicio local.

Paso 8. Probar desde fuera

Desde otro equipo o una red externa, ya podemos probar el subdominio:

curl https://ollama.tu-dominio.com/api/tags

Y también una llamada real al modelo:

curl https://ollama.tu-dominio.com/api/generate \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4",
    "prompt": "Prueba externa",
    "stream": false
  }'

Si esta prueba responde correctamente, el despliegue ya está funcionando.

Qué hemos conseguido con este enfoque

La ventaja de este sistema es que no hemos necesitado:

• abrir puertos en el router,

• contratar una IP fija,

• configurar DDNS,

• ni exponer directamente el puerto 11434 a Internet.

El túnel sale desde el propio servidor Linux hacia Cloudflare, y Cloudflare se encarga de enrutar las peticiones al servicio local de Ollama.

Siguiente paso recomendable

Una vez comprobado que el acceso funciona, el siguiente paso lógico es endurecer la seguridad.

Lo más recomendable es proteger ollama.tu-dominio.com con Cloudflare Access, de modo que solo determinados usuarios o servicios autorizados puedan consumir la API. Esto es especialmente importante si el endpoint va a ser utilizado por aplicaciones remotas, un VPS o un cliente como Jan.

Conclusión

Exponer Ollama con Cloudflare Tunnel es una forma práctica y limpia de publicar un modelo local hacia Internet sin complicarse con la IP del operador ni con configuraciones agresivas en el router.

En este caso, el flujo correcto ha sido:

1. comprobar Ollama en local,

2. instalar y autenticar cloudflared,

3. crear un túnel nombrado,

4. asociar el subdominio,

5. mapear el tráfico al servicio local,

6. arrancar el túnel,

7. y probar desde el exterior.

Con esto ya tenemos una base sólida para conectar clientes remotos y seguir evolucionando la arquitectura de forma más segura.

Si alguna vez has intentado mover un proyecto Laravel de tu entorno local a producción y te has encontrado con el clásico problema de "en mi máquina sí funciona", Docker es la solución que estabas buscando.

En este artículo, te voy a explicar cómo estructurar tu proyecto Laravel con Docker de forma profesional, cómo resolver los problemas más comunes (como el temido Connection refused) y te dejaré una lista interactiva (Cheat Sheet) de los comandos indispensables para tu día a día.

Estructura del Proyecto

Antes de entrar en detalle, así es como se organiza nuestro proyecto:

proyecto/
├── .dockerignore        ← Excluye archivos innecesarios del build
├── .env                 ← Única fuente de credenciales (¡NO commitear!)
├── .env.example         ← Plantilla documentada (SÍ commitear)
├── docker-compose.yml   ← Orquestador de todos los servicios
├── dockerfiles/
│   ├── entrypoint.sh    ← Script de arranque automático
│   ├── nginx.dockerfile
│   └── php.dockerfile
├── nginx/
│   └── default.conf     ← Configuración del servidor web
└── src/
    └── ...              ← Tu proyecto Laravel

** Detalle importante:** El fichero .dockerignore evita que carpetas como vendor/, node_modules/ o archivos .env se envíen al contexto de build de Docker, acelerando la construcción y evitando filtrar información sensible.

La Arquitectura: ¿Qué necesitamos?

Para ejecutar Laravel en Docker de forma robusta, dividimos nuestra aplicación en 4 contenedores (servicios) principales:

1. Servidor Web (Nginx): El encargado de recibir las peticiones HTTP y pasarlas a PHP. Configurado con cabeceras de seguridad y server_tokens off.

2. Aplicación (PHP-FPM): Donde reside el código fuente de Laravel y se ejecuta la lógica. Corre con un usuario no-root (laravel).

3. Base de Datos (MySQL): El almacenamiento persistente con un healthcheck que garantiza que esté lista antes de que PHP arranque.

4. Gestor de BD (phpMyAdmin) [Solo desarrollo]: Administración visual de la base de datos, activada solo con el perfil dev.

Todo esto lo orquestamos a través de un archivo maestro llamado docker-compose.yml.

Variables de Entorno: Una Única Fuente de Verdad

Una de las claves de seguridad más importantes es nunca hardcodear credenciales directamente en los ficheros de Docker. En su lugar, usamos un fichero .env centralizado en la raíz del proyecto.

1. Crea tu .env a partir de la plantilla

cp .env.example .env

2. Edita las credenciales en .env

# .env (raíz del proyecto — NO commitear)
APP_DEBUG=false
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=tu_contraseña_segura
MYSQL_ROOT_PASSWORD=otra_contraseña_segura

3. El docker-compose.yml las referencia con ${VARIABLE}

services:
  php:
    build:
      context: .
      dockerfile: dockerfiles/php.dockerfile
    restart: unless-stopped
    environment:
      - DB_CONNECTION=mysql
      - DB_HOST=mysql          # Usamos el nombre del servicio Docker, ¡no 127.0.0.1!
      - DB_PORT=3306
      - DB_DATABASE=${DB_DATABASE:-laravel}
      - DB_USERNAME=${DB_USERNAME:-laravel}
      - DB_PASSWORD=${DB_PASSWORD}
      - APP_DEBUG=${APP_DEBUG:-false}
    depends_on:
      mysql:
        condition: service_healthy  # Espera a que MySQL esté REALMENTE listo

** ¿Por qué no usamos src/.env?** Docker inyecta estas variables de entorno en el contenedor, sobrescribiendo las del .env de Laravel. Así se separa la configuración del código y se facilitan los despliegues automatizados en herramientas como Coolify o AWS.

Healthchecks: Arranque Inteligente

Uno de los problemas más comunes es que PHP intente conectar a MySQL cuando la base de datos aún no está lista. Para evitarlo, configuramos un healthcheck en MySQL:

mysql:
  image: mysql:8.0.32
  restart: unless-stopped
  healthcheck:
    test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
    interval: 5s
    timeout: 3s
    retries: 10
    start_period: 10s

Con depends_on: mysql: condition: service_healthy, Docker Compose esperará a que MySQL responda al ping antes de arrancar los contenedores de PHP y Nginx. ¡Adiós a los Connection refused en el arranque!

🛠️ Automatizando Migraciones y Seeders

El archivo entrypoint.sh se ejecuta cada vez que arranca el contenedor PHP. Automatiza las migraciones y ejecuta los seeders de forma inteligente:

#!/bin/sh
set -e

cd /var/www/html

echo "Database is ready. Running migrations..."
php artisan migrate --force

# Solo ejecutar seeders si existen ficheros Y no se han ejecutado antes
if [ ! -f /var/www/html/storage/.seeded ]; then
  SEEDER_COUNT=$(find /var/www/html/database/seeders -name '*.php' 2>/dev/null | wc -l)
  if [ "$SEEDER_COUNT" -gt 0 ]; then
    echo "Running seeders ($SEEDER_COUNT found)..."
    php artisan db:seed --force
    touch /var/www/html/storage/.seeded
  else
    echo "No seeders found, skipping."
  fi
else
  echo "Seeders already executed, skipping."
fi

exec "$@"

¿Qué hace de especial este script?

• set -e: Si cualquier comando falla, el contenedor se detiene inmediatamente (fail-fast).

• Seeders condicionales: Primero comprueba que existan ficheros .php en database/seeders. Si los hay y no se han ejecutado antes, se ejecutan y se crea un fichero marcador .seeded. En reinicios posteriores, se omite automáticamente.

** Importante:** Cualquier cambio en entrypoint.sh o en el php.dockerfile requiere que reconstruyas la imagen con el flag --build. ¡Si solo reinicias el contenedor usando restart, no se aplicarán los cambios!

Seguridad en Nginx

Nuestra configuración de Nginx incluye cabeceras de seguridad esenciales:

server {
    listen 80;
    server_name .localhost;
    root /var/www/html/public;

    # Ocultar versión de Nginx
    server_tokens off;

    # Cabeceras de seguridad
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Límites
    client_max_body_size 10M;
    fastcgi_read_timeout 60;

    # Bloquear acceso a ficheros ocultos
    location ~ /\.(?!well-known) {
        deny all;
    }
}

Estas cabeceras protegen contra ataques como clickjacking (X-Frame-Options), MIME-sniffing (X-Content-Type-Options) y ataques XSS (X-XSS-Protection).

phpMyAdmin: Solo en Desarrollo

phpMyAdmin se gestiona con un perfil de Docker Compose, lo que significa que solo se levanta cuando lo necesitas explícitamente:

phpmyadmin:
  image: phpmyadmin/phpmyadmin:latest
  profiles: ["dev"]    # Solo se activa con --profile dev
  depends_on:
    mysql:
      condition: service_healthy
  ports:
    - "127.0.0.1:8081:80"

En producción, phpMyAdmin no se despliega, eliminando una superficie de ataque innecesaria.

Cheat Sheet: Los Comandos que Usamos Todo el Tiempo

A continuación tienes una lista de los comandos más habituales al trabajar con contenedores, y los que te salvarán la vida en tu día a día (¡comprobado en este mismo blog!):

Comandos de Ciclo de Vida

Levantar tu proyecto o apagarlo:

• docker compose --profile dev up -d: Levanta todos los contenedores incluyendo phpMyAdmin (modo desarrollo).

• docker compose up -d: Levanta los contenedores sin phpMyAdmin (modo producción).

• docker compose up -d --build: Levanta los contenedores forzando la reconstrucción de las imágenes. Úsalo si cambias un Dockerfile o copias un nuevo entrypoint.sh.

• docker compose --profile dev up -d --build: Igual que el anterior, pero incluyendo phpMyAdmin.

• docker compose down: Detiene y destruye los contenedores y redes, pero conserva los volúmenes (tus bases de datos).

• docker compose down -v: Detiene y destruye todos los contenedores, redes y destruye los volúmenes (tus bases de datos).

• docker network inspect <nombre_red>: Útil si Docker te dice que una red sigue en uso y no te permite eliminar un entorno temporal.

Ejecutando código de Laravel dentro de Docker

Para usar php artisan y composer, no lo ejecutes en la terminal base de tu máquina (Windows/Mac), ya que intentará usar el PHP instalado localmente y probablemente fallará (por falta de dependencias u otras versiones de PHP). Ejecútalo dentro del contenedor:

• docker compose exec php php artisan migrate: Ejecuta las migraciones manualmente.

• docker compose exec php php artisan db:seed: Ejecuta los seeders para poblar datos de prueba o roles base.

• docker compose exec php php artisan config:clear: Limpia la caché de configuración. ¡Obligatorio si tocas tu .env local!

• docker compose exec --user root php composer dump-autoload: Regenera el autoload de Composer como super-usuario. Útil si pasas código creado en Windows a Linux y hay errores de permisos ("Operation not permitted").

Debugging y Logs

Cuando algo falla, como los errores HTTP 500, o un host laravel.localhost que devuelve "Connection Refused", la consola de comandos es tu mejor aliado para rastrear el fallo:

• docker compose logs php: Muestra lo que está pasando en el contenedor de PHP. Excelente para ver si el Entrypoint ejecutó las migraciones o si los seeders se saltaron correctamente.

• docker compose logs -f server: Sigue en tiempo real los logs de acceso (y errores 502 Bad Gateway) del servidor Nginx.

• docker compose ps: Comprueba qué contenedores están encendidos en ese momento. Con healthchecks, verás el estado healthy en MySQL.

• docker compose exec php ps aux: Verifica qué procesos internos (por ejemplo: php-fpm) se están ejecutando dentro del contenedor en ese preciso instante.

Reflexión Final

Dockerizar Laravel implica una curva de aprendizaje mínima al principio, pero una vez configuras tus volúmenes adecuadamente y entiendes cómo funciona su red interna, el flujo de trabajo es impecable.

Evitas conflictos de versiones (¡adiós a fallos por ejecutar Laravel 8 en PHP 8.3 local!), aislas tus bases de datos para no "manchar" tu sistema operativo y, lo mejor de todo, logras que el comportamiento local sea exactamente igual al del servidor de producción.

Con las mejoras de seguridad (variables externalizadas, cabeceras HTTP, perfiles para desarrollo) y fiabilidad (healthchecks, seeders condicionales), tu stack está preparado para un entorno profesional real.

¿Y tú, ya usas Docker en tus proyectos de Laravel o sigues usando XAMPP/Laragon? ¡Compárteme tu experiencia en los comentarios!

1. El Muro Frontal: Usaremos Cloudflare Zero Trust para obligar a cualquier visitante a iniciar sesión con tu cuenta de Google antes de ver tu web.

2. El Candado Trasero: Configuraremos el cortafuegos de Ubuntu (UFW) para que tu servidor rechace cualquier conexión directa a su IP pública, a menos que venga de Cloudflare o de tu propia casa.

PARTE 1: Configurar Cloudflare Zero Trust con Google

Requisito previo: Tu dominio debe estar gestionado en Cloudflare y con el proxy activado (la "nube naranja" en la pestaña DNS).

Paso 1.1: Obtener tu "Team Domain" en Cloudflare

Antes de ir a Google, necesitamos saber cuál es el identificador único de tu escudo en Cloudflare.

1. Entra en tu cuenta de Cloudflare y accede al panel de Zero Trust (en el menú lateral izquierdo).

2. Ve abajo del todo en el menú lateral y haz clic en Settings (Ajustes).

3. En las pestañas superiores, elige Team name.

4. Apunta o copia la URL exacta que aparece bajo Team domain (será algo parecido a https://tu-equipo.cloudflareaccess.com). ¡Guarda esta URL porque la usaremos ahora!

Paso 1.2: Crear las credenciales en Google Cloud

Vamos a autorizar a Cloudflare para que use los sistemas de inicio de sesión de Google como "portero".

1. Ve a la Consola de Google Cloud e inicia sesión con tu cuenta.

2. Crea un proyecto nuevo (ej. "Seguridad Servidor").

3. Ve a API y servicios > Pantalla de consentimiento de OAuth. Elige "Externo" y rellena tu email y el nombre de la app.

4. Ve a Credenciales > Crear credenciales > ID de cliente de OAuth y selecciona Aplicación web.

5. En Orígenes de JavaScript autorizados, pega tu Team Domain de Cloudflare: https://tu-equipo.cloudflareaccess.com

6. En URI de redireccionamiento autorizados, pega tu Team Domain seguido de la ruta de respuesta: https://tu-equipo.cloudflareaccess.com/cdn-cgi/access/callback

7. Haz clic en Crear. Copia el ID de cliente y el Secreto de cliente que aparecerán en pantalla.

Paso 1.3: Conectar Google con Cloudflare

1. Vuelve al panel de Zero Trust en Cloudflare.

2. En el menú lateral izquierdo, ve a Integrations > Identity providers.

3. Haz clic en Add new identity provider y selecciona Google.

4. Pega el ID y el Secreto de cliente que copiaste de Google y haz clic en Save.

Paso 1.4: Proteger tu dominio (Crear la Aplicación y la Política)

1. En el menú lateral de Zero Trust, ve a Access controls > Applications y pulsa Add an application. Selecciona Self-hosted.

2. Pestaña 1 (Configuración): Ponle un nombre (ej. OpenClaw-Admin). En Public hostname, escribe tu subdominio (ej. openclaw) y selecciona tu dominio (ej. tudominio.com). Pulsa Next.

3. Pestaña 2 (La Política VIP): Ponle un nombre a la regla (ej. SoloYo) y asegúrate de que la acción es Allow.

4. En la sección Include, abre el desplegable Selector y elige Emails. En el campo Value, escribe tu correo de Google exacto. Pulsa Next y luego Add application.

PARTE 2: Cerrar la "Puerta Trasera" con UFW en Ubuntu

Si alguien averigua la IP pública de tu servidor, podría escribirla en su navegador y saltarse todo el muro de Cloudflare. Vamos a blindar el servidor para que solo hable con Cloudflare.

Paso 2.1: Limpiar las reglas web abiertas (El método infalible)

Conéctate por SSH a tu servidor. Vamos a ver las reglas de tu cortafuegos numeradas para no cometer errores al borrarlas:

sudo ufw status numbered

Debes borrar todas las reglas que abran los puertos 80, 443 o el puerto directo de tu aplicación (ej. 18789), dejando viva ÚNICAMENTE la regla de OpenSSH. Para borrar una regla, usa su número (siempre borrando de los números más altos a los más bajos para que no se desordenen). Ejemplo:

sudo ufw delete 4

Paso 2.2: Permitir exclusivamente las IPs de Cloudflare

Copia y pega estos dos bloques de código en tu terminal para descargar la lista oficial de IPs de Cloudflare y permitirlas en tu servidor:

for i in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $i to any port 80,443 proto tcp
done

for i in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $i to any port 80,443 proto tcp
done

Paso 2.3: (Opcional) Permitir tu IP personal para uso de DNS Local

Si planeas modificar el archivo hosts de tu ordenador para acceder directamente a la IP del servidor usando el subdominio (haciendo Split DNS), Cloudflare no intervendrá y el UFW te bloqueará. Para evitarlo, añade la IP pública de tu casa a la lista de permitidos:

sudo ufw allow from TU_IP_PERSONAL to any port 80,443 proto tcp

Paso 2.4: Recargar el Firewall

Aplica todos los cambios blindando el sistema:

sudo ufw reload

¡Misión cumplida! Tu servidor es ahora una fortaleza. Nadie puede acceder a tus aplicaciones web sin pasar por el inicio de sesión de Google administrado por Cloudflare, y la puerta trasera directa a tu IP está cerrada a cal y canto.

A continuación, te explicamos cómo configurarlo, tanto si tienes OpenClaw instalado de forma nativa en tu servidor Linux, como si usas Docker.

Método 1: Instalación Nativa (Sin Docker) - Recomendado

Conéctate a tu servidor por SSH con el usuario administrador donde instalaste OpenClaw y lanza el asistente directamente hacia la configuración de Codex:

openclaw onboard --out choice open codex

Respuestas durante el asistente (Onboarding)

Al ejecutar el comando, la terminal se volverá interactiva. Aquí tienes lo que debes responder a cada pregunta:

1. Advertencia de riesgo: El sistema te preguntará si entiendes que usar cuentas web tiene riesgos (como que OpenAI te cierre la sesión). Escribe "Yes" o pulsa "Y" y presiona Enter.

2. Quick Start: Si te aparece una opción de "Quick start", simplemente pulsa Enter para continuar.

3. Actualizar valores: Te preguntará si quieres usar los valores existentes o actualizarlos. Utiliza las flechas del teclado para seleccionar "Update values" (Actualizar valores) y pulsa Enter.

4. La Autenticación: La terminal generará una URL larga. Cópiala, pégala en el navegador de tu ordenador e inicia sesión con la cuenta donde pagas ChatGPT Plus.

5. El "error" de Localhost: Al darle a "Continuar" en la web, la página parecerá romperse y te llevará a una dirección que empieza por http://localhost.... ¡No te asustes, es normal! Copia toda esa URL de la barra de direcciones, vuelve a tu terminal, pégala y pulsa Enter.

6. Seleccionar canal: El asistente te preguntará qué canal de chat quieres usar. Elige el que ya tenías configurado (por ejemplo, Telegram) para mantenerlo.

7. Configure Skills (Habilidades): Selecciona "No" (es mejor configurarlas más adelante).

8. Enable Hooks: Selecciona "Skip for now" (Saltar por ahora).

Una vez finalizado el asistente, reinicia la pasarela principal para aplicar el nuevo cerebro:

openclaw gateway restart

Método 2: Instalación con Docker

Si optaste por aislar tu entorno usando contenedores Docker, los pasos y las respuestas al asistente son exactamente los mismos que en el Método 1, pero debes lanzar el comando a través de Docker.

Sustituye tu_contenedor por el nombre real de tu contenedor (suele ser openclaw):

sudo docker exec -it tu_contenedor openclaw onboard --out choice open codex

Responde a las preguntas del asistente tal y como explicamos en el Método 1. Al terminar, OpenClaw no podrá reiniciarse solo dentro de Docker, así que fuerza el reinicio manualmente:

sudo docker restart tu_contenedor

Paso Final: Seleccionar y Verificar el Nuevo Modelo

Una vez reiniciado el sistema, debes comprobar que la conexión funciona correctamente.

Desde tu aplicación de mensajería (Telegram/WhatsApp)

Abre el chat con tu bot y envíale este comando para ver su estado actual:

/status

Si no detecta el modelo automáticamente, despliega el menú interactivo enviando:

/model

Selecciona tu nueva conexión Plus (Codex) en la lista.

Desde la terminal del servidor (Para usuarios avanzados)

Puedes ver un reporte profundo del estado de tus tokens y modelos ejecutando:

openclaw models status

Y para fijar el modelo de OpenAI Codex como el predeterminado para todas las sesiones, ejecuta (ajusta el nombre si el status te da uno ligeramente distinto):

openclaw models set openai/codex

En este tutorial, vamos a instalar la versión oficial de Caddy en nuestro servidor Ubuntu 24.04 (previamente securizado) y lo dejaremos listo para servir nuestra primera web o aplicación.

Paso 1: Instalar dependencias necesarias

Conéctate a tu servidor por SSH con tu usuario administrador (con permisos sudo) y asegúrate de tener instalados los paquetes básicos para poder descargar repositorios externos de forma segura:

sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

Paso 2: Añadir el repositorio oficial de Caddy

Para asegurarnos de tener siempre la última versión estable, vamos a descargar e instalar la llave GPG oficial de Caddy y a añadir su repositorio a nuestro sistema.

Primero, descarga la llave GPG:

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

Luego, añade el repositorio a tu lista de fuentes (sources.list):

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

Paso 3: Instalar Caddy

Ahora que el sistema sabe de dónde descargar Caddy, simplemente actualiza la lista de paquetes e instálalo:

sudo apt update
sudo apt install caddy -y

Una vez terminada la instalación, Caddy se inicia automáticamente como un servicio del sistema. Puedes verificar que está corriendo felizmente con:

sudo systemctl status caddy

Paso 4: Abrir los puertos en el Firewall (UFW)

Si seguiste nuestra guía de seguridad anterior, recordarás que cerramos todos los puertos excepto el del SSH. Para que el mundo pueda ver tus páginas web, necesitamos abrir los puertos HTTP (80) y HTTPS (443):

sudo ufw allow 80,443/tcp
sudo ufw reload

Si ahora introduces la IP pública de tu servidor en tu navegador web, verás la página de bienvenida por defecto de Caddy. ¡Funciona!

Paso 5: Conociendo el Caddyfile

Toda la magia de Caddy ocurre en un único archivo de configuración llamado Caddyfile. Se encuentra en la ruta /etc/caddy/Caddyfile.

Para editarlo, usa tu editor de texto favorito:

sudo nano /etc/caddy/Caddyfile

Un ejemplo básico para servir una web estática o hacer un proxy inverso hacia una aplicación (como un bot o una API) sería tan simple como esto:

tudominio.com {
    reverse_proxy localhost:3000
}

Con esas tres simples líneas, Caddy generará el certificado SSL gratis, forzará la conexión a HTTPS y redirigirá el tráfico al puerto interno 3000 de tu servidor.

Siempre que modifiques el Caddyfile, recuerda recargar el servicio para aplicar los cambios sin apagar el servidor:

sudo systemctl reload caddy

¡Y eso es todo! Tienes un servidor web de última generación funcionando de forma segura. Adiós a las renovaciones manuales de certificados y a las configuraciones interminables.

En este tutorial, aprenderás a preparar y blindar tu servidor con Ubuntu 24.04 paso a paso antes de instalar cualquier aplicación.

Paso 1: Actualizar el sistema base

Lo primero que debes hacer al entrar a tu servidor por primera vez es asegurarte de que todos los paquetes y parches de seguridad estén al día. Abre tu terminal, conéctate por SSH como root y ejecuta:

apt update && apt upgrade -y

Paso 2: Crear un usuario administrador (Sudo)

No usaremos root para las tareas diarias. Vamos a crear un usuario estándar y le otorgaremos permisos de administrador para cuando los necesite.

Ejecuta el siguiente comando para crear el usuario (sustituye tu_usuario por el nombre que desees):

adduser tu_usuario

El sistema te pedirá que asignes una contraseña segura y algunos datos adicionales que puedes omitir pulsando la tecla Enter. A continuación, dale permisos de administrador a este nuevo usuario:

usermod -aG sudo tu_usuario

Paso 3: Configurar el Firewall (UFW)

Ubuntu incluye un cortafuegos muy sencillo de usar llamado UFW, pero viene desactivado por defecto. Vamos a encenderlo permitiendo únicamente el tráfico esencial.

Permite las conexiones SSH (puerto 22) para no quedarte bloqueado fuera del servidor:

ufw allow OpenSSH

Activa el firewall:

ufw enable

Paso 4: Configurar el acceso mediante claves SSH

Para evitar ataques de fuerza bruta basados en contraseñas, configuraremos el acceso por llaves criptográficas.

En tu ordenador personal (NO en el servidor):
Abre la terminal de tu PC o Mac y genera un par de claves con cifrado moderno:

ssh-keygen -t ed25519 -C "tu_correo@ejemplo.com"

1. El Muro Frontal: Usaremos Cloudflare Zero Trust para obligar a cualquier visitante a iniciar sesión con tu cuenta de Google antes de ver tu web.

2. El Candado Trasero: Configuraremos el cortafuegos de Ubuntu (UFW) para que tu servidor rechace cualquier conexión directa a su IP pública, a menos que venga de Cloudflare.

PARTE 1: Configurar Cloudflare Zero Trust con Google

Requisito previo: Tu dominio debe estar gestionado en Cloudflare y con el proxy activado (la "nube naranja" en la pestaña DNS).

Paso 1.1: Obtener tu "Team Domain" en Cloudflare

1. Accede al panel de Zero Trust en Cloudflare.

2. Ve abajo del todo en el menú lateral y haz clic en Settings.

3. En las pestañas superiores, elige Team name.

4. Apunta la URL que aparece bajo Team domain (ej. https://tu-equipo.cloudflareaccess.com). ¡Guárdala porque la usaremos ahora!

Paso 1.2: Crear las credenciales en Google Cloud

1. Ve a la Consola de Google Cloud e inicia sesión.

2. Crea un proyecto nuevo.

3. Ve a API y servicios > Pantalla de consentimiento de OAuth. Elige "Externo" y rellena tus datos.

4. Ve a Credenciales > Crear credenciales > ID de cliente de OAuth (Aplicación web).

5. En Orígenes de JavaScript autorizados, pega tu Team Domain: https://tu-equipo.cloudflareaccess.com

6. En URI de redireccionamiento autorizados, añade: https://tu-equipo.cloudflareaccess.com/cdn-cgi/access/callback

7. Haz clic en Crear. Copia el ID de cliente y el Secreto de cliente.

Paso 1.3: Conectar Google con Cloudflare

1. Vuelve al panel de Zero Trust.

2. Ve a Integrations > Identity providers.

3. Haz clic en Add new identity provider y selecciona Google.

4. Pega el ID y el Secreto de cliente y guarda.

Paso 1.4: Proteger tu dominio (Crear el Muro)

1. Ve a Access controls > Applications y pulsa Add an application (Self-hosted).

2. Pestaña 1: Ponle un nombre. En Public hostname, escribe tu subdominio (ej. openclaw) y selecciona tu dominio. Pulsa Next.

3. Pestaña 2: Ponle un nombre a la política (ej. Administrador) y asegúrate de que la acción es Allow.

4. En Include, elige Emails en el Selector y escribe tu correo exacto. Pulsa Next y guarda.

PARTE 2: Cerrar la "Puerta Trasera" con UFW

Vamos a blindar el servidor para que solo hable con Cloudflare y bloquee intentos de acceso por IP directa.

Paso 2.1: Limpiar las reglas web abiertas

Conéctate por SSH y lista tus reglas numeradas:

sudo ufw status numbered