Cómo desplegar SafeLine WAF en un VPS Linux

Las aplicaciones web expuestas a Internet son sondeadas de forma habitual en busca de inyecciones SQL, abuso de credenciales y patrones de vulnerabilidades conocidas. SafeLine es un WAF autoalojado con licencia GPL-3.0 que se ejecuta como un stack de Docker Compose y filtra el tráfico HTTP/S antes de reenviar las solicitudes permitidas al origen. Su plan Personal gratuito admite hasta 10 aplicaciones.

Este tutorial cubre la instalación y tres áreas que requieren atención especial: la decisión sobre la arquitectura del proxy inverso, la configuración de la red Docker cuando SafeLine se sitúa detrás de un proxy existente como Nginx Proxy Manager, y un comando de verificación que puedes ejecutar tras la instalación para confirmar que el WAF realmente está interceptando ataques.

La versión corta

• Instala SafeLine en un VPS Linux con Docker Compose. Usa el instalador de una sola línea o toma la vía manual de Docker Compose para inspeccionar la definición de Compose y la configuración del entorno antes de arrancar el stack.
• Decide la arquitectura del proxy inverso antes de instalar: SafeLine como único proxy, SafeLine detrás de un Nginx Proxy Manager existente, o SafeLine compartiendo el servidor con Caddy. Cada configuración necesita asignaciones de puertos y ajustes de X-Forwarded-For distintos.
• Tras la instalación, verifica el WAF enviando una sonda de inyección SQL con curl a la URL protegida. En modo Balanced o Strict, una respuesta 403 junto con una entrada coincidente en Attack Events confirma el bloqueo. En modo Monitor, el evento coincidente confirma la detección aunque la respuesta pueda seguir siendo exitosa.
• El plan Personal gratuito cubre hasta 10 aplicaciones y el motor de detección principal. El geobloqueo, la exportación de registros de ataques y las notificaciones externas requieren el plan Lite; una detección de ataques más potente y el balanceo de carga requieren Pro.

Antes de empezar: requisitos previos y qué cubre este tutorial

Este tutorial asume que dispones de un VPS Linux al que puedes conectarte por SSH con acceso root o sudo, y que Docker está instalado. Terminarás con una instancia de SafeLine funcionando y protegiendo al menos un sitio, además de un comando de verificación que puedes volver a ejecutar en cualquier momento.

Necesitas:

• Un VPS Linux. Los comandos siguientes asumen un sistema de tipo Debian o Ubuntu con systemd; verifica los nombres de paquetes y servicios en otras distribuciones.
• Al menos 1 vCPU, 1 GB RAM y 5 GB de disco según los requisitos de despliegue oficiales. Para un margen práctico en producción, esta guía recomienda 2 vCPU, 4 GB RAM y 20 GB de disco.
• Docker 20.10.14 o posterior y Docker Compose 2.0 o posterior.
• Una CPU x86_64 con soporte SSSE3; verifícalo con lscpu | grep ssse3 en lugar de asumir que la instrucción está presente.
• Un dominio o subdominio con DNS apuntando a la IP pública del VPS si planeas exponer la aplicación protegida por HTTPS público.
• Puertos apropiados para la topología seleccionada. Las configuraciones A y C normalmente asignan a SafeLine los puertos 80 y 443, mientras que la configuración B deja esos puertos a Nginx Proxy Manager y asigna a SafeLine un escuchador distinto como el 10080.
• Acceso root o sudo.

En el firewall o grupo de seguridad del proveedor del VPS, expón solo los puertos públicos que necesite la topología seleccionada. Restringe SSH y TCP 9443 a fuentes de administración de confianza. En la configuración B, mantén el TCP 10080 cerrado a IPv4 e IPv6 públicas, y mantén los puertos de backend como el 8080 privados en todas las topologías. El acceso directo al 10080 eludiría NPM e invalidaría el límite de confianza de X-Forwarded-For.

Nota: Para un despliegue manual en ARM64, define ARCH_SUFFIX=-arm. La documentación de despliegue oficial de SafeLine indica que ARM requiere una licencia Pro y que la edición Personal no es compatible con ARM. Usa un VPS x86_64 para la edición Personal.

Verifica Docker antes de empezar:

docker --version
docker compose version

Ambos comandos deben devolver las versiones instaladas. Continúa solo si Docker es la versión 20.10.14 o posterior y Docker Compose es la versión 2.0.0 o posterior; de lo contrario, actualiza antes de instalar SafeLine.

Elige primero la arquitectura de tu proxy inverso

Un VPS nuevo permite que SafeLine controle por completo los puertos 80 y 443. Un VPS que ya ejecuta Nginx Proxy Manager, Caddy o el propio Nginx de la aplicación no lo permite, y la decisión de arquitectura es la diferencia entre una instalación sin problemas y un conflicto de puertos en el primer arranque. Acierta con esto una vez al principio y el resto del despliegue es mecánico.

Las tres configuraciones:

• Configuración A, SafeLine como único proxy inverso. SafeLine controla los puertos 80 y 443 y gestiona TLS para la aplicación protegida. Las versiones actuales de CE incluyen un flujo de trabajo de certificados gratuitos (Free Cert), y la carga manual de certificados sigue disponible; verifica las opciones de certificado exactas en la versión instalada. El backend se ejecuta en un puerto no público y SafeLine enruta hacia él.
• Configuración B, SafeLine detrás de Nginx Proxy Manager (NPM). NPM conserva los puertos 80 y 443 y gestiona SSL. SafeLine escucha en el puerto 10080 (solo HTTP, ya que NPM ya terminó el TLS). NPM reenvía a SafeLine; SafeLine reenvía al backend. Esta es una configuración habitual cuando NPM ya está desplegado.
• Configuración C, SafeLine junto a Caddy. El HTTPS automático de Caddy compite con SafeLine por el puerto 443. Una disposición viable asigna a SafeLine los puertos 80 y 443, y traslada Caddy a un puerto HTTP interno no público como el 8080 para el salto de SafeLine a Caddy a la aplicación.

Conclusión clave: La configuración A es la más sencilla para un VPS nuevo; la configuración B es la opción adecuada cuando NPM ya está en ejecución; la configuración C requiere una reasignación deliberada del puerto de Caddy.

Instala SafeLine en tu VPS

La instalación en sí es la parte fácil. SafeLine ofrece dos vías de instalación: un instalador automatizado que descarga un script remoto de waf.chaitin.com, y una vía manual con Docker Compose que te permite inspeccionar todo antes de ejecutarlo. Elige la que se ajuste a tu política de seguridad.

Paso 1: confirma que Docker está listo

Vuelve a comprobar la versión de Docker y que el demonio de Docker está en ejecución:

docker --version
docker compose version
sudo systemctl status docker

La salida esperada incluye active (running) para el demonio de Docker. Si no está en ejecución, arráncalo con sudo systemctl start docker y habilítalo en el arranque con sudo systemctl enable docker.

Paso 2: ejecuta el instalador de SafeLine

Hay dos subvías. Elige una.

Paso 2a, instalación automatizada. Ejecuta el instalador con privilegios de root:

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

El script pregunta dónde ubicar el directorio de datos de SafeLine, descarga las imágenes de Docker y arranca el stack. Tras la instalación, ejecuta sudo docker exec safeline-mgt resetadmin para recuperar o restablecer las credenciales de administrador, tal como se describe en la guía de despliegue oficial. Guarda de forma segura las credenciales resultantes.

Nota: Este comando descarga y ejecuta un script de shell remoto de waf.chaitin.com como root. El comando oficial de una sola línea incluye curl -k, que deshabilita la verificación de certificados TLS. Revisa el script descargado antes de ejecutarlo, o usa el paso 2b si ese riesgo es inaceptable. SafeLine también está disponible como despliegue de un clic de Cloudzy, pero esa imagen usa /opt/safeline, /opt/safeline/.env, y /opt/safeline/docker-compose.yml. No uses las /data/safeline rutas de esta guía sin modificar en la imagen de Cloudzy.

Paso 2b, instalación manual con Docker Compose. Descarga e inspecciona el archivo Compose oficial, luego arranca el stack:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Después de docker compose up -d termina, lista los contenedores en ejecución para confirmar:

sudo docker compose ps

Deberías ver contenedores para safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi y safeline-chaos. Si algún contenedor muestra Exited, consulta el paso 3 para las dos causas más comunes.

Paso 3: resuelve errores de instalación comunes

Dos errores aparecen con la suficiente frecuencia como para merecer su propio paso.

Solapamiento de subred. Si la instalación falla con Pool overlaps with other one on this address space, la subred predeterminada de SafeLine entra en conflicto con una red Docker existente. Como se documenta en un tutorial de resolución de problemas de instalación de SafeLine, corrígelo editando /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Error del resolutor IPv6. Si safeline-tengine se bloquea con nginx: [emerg] invalid IPv6 address in resolver, primero inspecciona el archivo del resolutor y determina quién lo gestiona:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

No edites /etc/resolv.conf directamente si lo genera systemd-resolved, NetworkManager o el proveedor del VPS. Corrige el valor de nameserver mal formado en la configuración del servicio que lo gestiona, regenera el archivo del resolutor y luego reinicia Tengine:

sudo docker restart safeline-tengine

Paso 4: accede al panel de control

El panel de administración de SafeLine escucha en TCP 9443 sobre HTTPS. No dejes este puerto administrativo abierto a todo Internet. Restríngelo a una dirección de origen de confianza o a una VPN, o bloquea el acceso público y usa un túnel SSH:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Abre https://localhost:9443 a través del túnel. Es normal recibir una advertencia de certificado autofirmado en el primer acceso; verifica que la conexión SSH llegó al servidor previsto antes de continuar.

Si perdiste las credenciales iniciales, restablece la contraseña de administrador desde el host:

sudo docker exec safeline-mgt resetadmin

El comando imprime credenciales de administrador que puedes usar para volver a iniciar sesión.

Configura SafeLine para tu arquitectura

SafeLine ya está en ejecución, pero todavía no protege nada. La página Applications del panel es donde le indicas a SafeLine qué sitios proteger y adónde reenviar el tráfico depurado. La configuración difiere según la arquitectura que elegiste antes, así que cada configuración tiene su propia subsección. Sigue solo la que coincida con tu montaje.

Configuración A: SafeLine como único proxy inverso

Para la configuración A, SafeLine escucha directamente en los puertos 80 y 443 y reenvía el tráfico depurado a tu aplicación de backend en un puerto no público. En el panel:

1. Ve a Applications y luego Add Application.
2. Establece el puerto de escucha en 443 y habilita SSL. Usa el flujo de trabajo de certificados disponible en la versión de SafeLine que tengas instalada. Las versiones actuales de CE incluyen la solicitud y gestión de renovación de certificados gratuitos (Free Cert), y la carga manual de certificados sigue disponible.
3. Establece el upstream en http://127.0.0.1:8080. Si el backend se ejecuta en Docker, publica su puerto solo en loopback, por ejemplo "127.0.0.1:8080:8080" en la sección de puertos del servicio. Evita una IP de contenedor codificada como 172.17.0.5 porque puede cambiar cuando el contenedor se recrea.
4. Guarda la aplicación. SafeLine empieza a escuchar de inmediato en el 443 y a reenviar el tráfico depurado al backend.
5. Confirma que el registro DNS A de tu dominio apunta a la IP pública del VPS y que los puertos 80 y 443 son accesibles desde el exterior.

Si el puerto 443 ya estaba ocupado por otro proceso, el contenedor de SafeLine no podrá vincularse y el panel mostrará un error en esa aplicación. Detén el proceso en conflicto, o elige un puerto distinto, antes de añadir la aplicación.

Configuración B: SafeLine detrás de Nginx Proxy Manager

La configuración B mantiene a NPM haciendo lo que ya hace (controlar el 80 y el 443, gestionar Let's Encrypt) e inserta SafeLine como una capa de seguridad dedicada detrás de él. El flujo de tráfico es: cliente, luego NPM (puerto 443, terminación TLS), luego SafeLine (puerto 10080, HTTP), y luego la aplicación de backend.

Dentro del panel de SafeLine:

1. Applications y luego Add Application. Establece el puerto de escucha en 10080 y deja SSL desactivado (NPM ya terminó el TLS).
2. Establece el upstream en la dirección interna de la aplicación, tal como se describe en la configuración A.
3. Guarda la aplicación.

En Nginx Proxy Manager:

1. Hosts, luego Proxy Hosts, luego Add Proxy Host.
2. Pestaña Details: establece el nombre de dominio, el esquema http, y el puerto de reenvío 10080. Si NPM se ejecuta directamente en el host, usa 127.0.0.1 como nombre de host de reenvío. Si NPM se ejecuta en Docker sobre Linux, 127.0.0.1 apunta al contenedor de NPM en lugar de al host del VPS. Añade el mapeo host-gateway de Docker al servicio Compose de NPM, luego usa host.docker.internal como nombre de host de reenvío:

extra_hosts:
  - "host.docker.internal:host-gateway"

Desde el directorio Compose de NPM, ejecuta sudo docker compose up -d para que el contenedor se recree con el nuevo mapeo de host.

3. Pestaña SSL: solicita un certificado de Let's Encrypt, fuerza SSL y habilita HTTP/2.
4. Deja vacía la pestaña Advanced de NPM en lo relativo a X-Forwarded-For. En la plantilla actual de NPM, el contenido de Advanced se inserta en el ámbito del servidor y no anula las cabeceras de nivel de location generadas según las reglas de herencia de NGINX. La location generada envía:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

La segunda directiva añade la dirección observada por NPM como el valor situado más a la derecha en la cabecera.

5. Guarda el Proxy Host.

De vuelta en SafeLine, configura la extracción de la IP de origen solo después de confirmar la cadena de cabeceras efectiva. SafeLine 9.3.1 introdujo una extracción flexible de XFF con selección de dirección e índice.

1. Settings, luego Advanced, luego Real IP from Header. Establece el nombre de la cabecera en X-Forwarded-For.
2. Usa la extracción personalizada desde el final de la cabecera y selecciona la dirección situada más a la derecha añadida por NPM. Las etiquetas exactas de los índices varían según la versión, así que verifica el resultado en Logs, luego Access. Si la versión instalada es anterior a la 9.3.1, actualízala antes de seguir esta topología.
3. Si Cloudflare u otro CDN se sitúa delante de NPM, configura primero NPM para que confíe solo en los rangos de proxy publicados por ese proveedor, de modo que la dirección añadida por NPM sea fiable. No selecciones una posición fija hasta que hayas inspeccionado y probado la cadena de cabeceras real.
4. Guarda y recarga la aplicación.

Prueba la configuración desde una máquina externa al VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

El registro de acceso de SafeLine debería mostrar tu dirección pública real, no 1.2.3.4 ni la dirección de puente de NPM.

Impide que los usuarios eludan SafeLine manteniendo privado el escuchador del backend. Para un backend con Docker Compose, publica el puerto solo en loopback:

ports:
  - "127.0.0.1:8080:8080"

Para un servicio que se ejecuta directamente en el host, configúralo para que escuche en 127.0.0.1:8080 en lugar de 0.0.0.0:8080. Verifica ambos puertos internos desde una máquina externa al VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

Las conexiones TCP deberían rechazarse o agotar el tiempo de espera. Un error HTTP o "Empty reply from server" sigue significando que el puerto es accesible públicamente y debe protegerse. Si la vinculación a loopback es imposible, crea reglas de firewall adaptadas a la interfaz real, la red Docker y el contenedor de destino en lugar de aplicar una regla DOCKER-USER genérica.

Configuración C: SafeLine con Caddy

Para la configuración C, SafeLine toma los puertos 80 y 443; Caddy se traslada a un puerto HTTP interno no público. El flujo de tráfico es: cliente, luego SafeLine (443, TLS), luego Caddy (8080, HTTP interno), y luego el backend de la aplicación.

Editar /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

El :8080 El bloque de sitio es la parte importante: Caddy ahora escucha en un puerto HTTP interno en lugar de competir con SafeLine por el 443. La bind 127.0.0.1 línea mantiene ese escuchador local al VPS. Recarga Caddy con sudo systemctl reload caddy y confirma con sudo ss -ltnp | grep -E ':(443|8080)' que Caddy está vinculado al 8080, no al 443.

En SafeLine, añade una aplicación que escuche en el 443 con SSL habilitado, luego establece el upstream en http://127.0.0.1:8080. El ajuste de X-Forwarded-For puede permanecer en la opción predeterminada de conexión de red porque Caddy está detrás de SafeLine, no delante.

Elige un modo de protección y verifica que el WAF está bloqueando ataques

SafeLine tiene tres modos de protección que deciden qué ocurre cuando el motor marca una solicitud como maliciosa. El modo inicial adecuado depende de la aplicación; el paso de verificación es el mismo en cualquier modo.

Modos de protección: Monitor, Balanced, Strict

Cada aplicación en SafeLine tiene su propia configuración de modo de protección, ajustable en Applications, luego tu aplicación, luego Protection Mode:

• Monitor. SafeLine registra las solicitudes que de otro modo bloquearía, pero no las bloquea. Este es el punto de partida más seguro para una aplicación de producción compleja con formularios de entrada ricos (un foro, un panel de administración con campos WYSIWYG, una API que acepta cargas JSON de formato libre). Ejecuta Monitor durante unos días, revisa la página Attack Events y confirma que no hay falsos positivos frente a usuarios reales antes de pasar a Balanced.
• Balanced. El modo predeterminado. Las cifras publicadas por el proveedor en GitHub de SafeLine reportan un 71.65% de detección, un 99.45% de precisión y una tasa de falsos positivos del 0.07% para el modo Balanced. Se informa que el modo Strict tiene un 76.17% de detección, un 99.38% de precisión y una tasa de falsos positivos del 0.22%. Estos son resultados reportados por el proveedor y no una prueba comparativa independiente, y el README no identifica el conjunto de datos como WAF-Eval. Considéralos como cifras comparativas del producto, no como un rendimiento de producción garantizado.
• Strict. Un conjunto de reglas más agresivo con heurísticas más estrictas y el compromiso entre detección y falsos positivos mostrado arriba. Merece la pena probarlo tras una o dos semanas de funcionamiento limpio en Balanced, una vez que entiendas tu tráfico.

Recomendación: Balanced para un despliegue nuevo sin tráfico en vivo que perturbar. Para una aplicación de producción existente, empieza en Monitor durante unos días, busca falsos positivos en el registro de Attack Events y pasa a Balanced una vez que hayas ajustado las excepciones. Merece la pena probar Strict tras una o dos semanas en Balanced una vez que entiendas tu tráfico.

Verifica el WAF con una prueba de SQLi mediante curl

El último paso antes de dar por terminada la instalación es confirmar que el WAF realmente intercepta un ataque. Ejecuta una sonda de inyección SQL benigna contra tu sitio protegido desde cualquier máquina externa al VPS:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Este es el vector de prueba de inyección SQL publicado por SafeLine. En modo Balanced o Strict, espera un estado 403 y una respuesta de bloqueo de SafeLine. En modo Monitor, espera que la solicitud se registre sin bloquearse. La versión de HTTP y el cuerpo exacto de la respuesta pueden variar, así que confirma el resultado con una entrada coincidente en Attack Events.

Luego abre el panel mediante el método de acceso restringido del paso 4 y navega a Logs, luego Attack Events. Deberías ver una nueva entrada con la marca de tiempo coincidente, el tipo de ataque SQL Injection, la IP de origen coincidente con la máquina desde la que ejecutaste curl y la cadena de consulta ofensiva en el detalle de la solicitud. Haz clic en el evento para ver la solicitud y la respuesta completas capturadas por SafeLine.

Si la solicitud de curl devolvió 200 OK, interpreta el resultado junto con el registro de Attack Events:

• Un evento SQL Injection coincidente significa que la aplicación probablemente está en modo Monitor; es de esperar que registre sin bloquear.
• Si no hay ningún evento coincidente, confirma que el DNS resuelve al VPS previsto, verifica el escuchador de SafeLine y la configuración del upstream, y correlaciona la hora de la solicitud con el registro de acceso de SafeLine.
• Confirma también que la protección está habilitada y que ninguna lista blanca de IP, regla de permiso personalizada o excepción de ruta cubre la solicitud de prueba.

Conclusión clave: Si la sonda de curl devuelve 403 con la página de interceptación de SafeLine y aparece una entrada en Attack Events con el tipo de ataque SQL Injection, el WAF está interceptando el tráfico correctamente.

Qué cubre el plan gratuito y qué requiere un plan de pago

El plan Personal gratuito es suficiente para proteger la mayoría de los despliegues en un solo VPS. Los planes de pago empiezan a importar cuando necesitas funciones operativas (notificaciones, exportación de registros, geobloqueo) o superas el límite de 10 aplicaciones.

El desglose, tomado de la página de precios de CyberServal:

• Personal, gratuito. Hasta 10 aplicaciones. Incluye el motor de detección semántica (SQLi, XSS, inyección de comandos, path traversal, SSRF, XXE, CRLF), limitación de tasa, desafío CAPTCHA contra bots, cifrado dinámico de HTML/JS contra scrapers automatizados, reglas ACL web y gestión de certificados. Las versiones actuales de CE también incluyen la solicitud y gestión de renovación de certificados gratuitos (Free Cert).
• Lite, $10/mes o $100/año. Añade geobloqueo, la base de datos de IP de inteligencia de amenazas, integración de notificaciones con Discord y Telegram, exportación de registros de ataques y eleva el límite de aplicaciones a 20.
• Pro, $100/mes o $1,000/año. Añade una detección de ataques más potente, configuraciones por servicio y globales, páginas de interceptación personalizadas, balanceo de carga del upstream, sincronización de nodos maestro-esclavo y aplicaciones ilimitadas. Consulta la tabla de precios actual para ver los cambios.
• Ultimate, precio personalizado. Términos empresariales a medida con soporte individual en varios canales y desarrollo de funciones personalizadas.

SafeLine procesa y almacena los datos de la aplicación dentro de su stack de Compose local. No obstante, las notas de la versión actual de CE mencionan el intercambio de inteligencia de amenazas (Threat Intelligence Sharing), por lo que los operadores deberían revisar los controles de UEP, privacidad e intercambio de la versión instalada y observar las conexiones salientes antes de considerar el despliegue como de salida nula.

Qué hacer a partir de aquí

La instalación está completa y el WAF verificado. Algunas tareas de seguimiento ayudarán a mantener el despliegue en buen estado.

• Para cualquier aplicación de producción con entradas de usuario ricas (un foro, un panel de administración, una API de formato libre), establece el modo de protección en Monitor durante tres a siete días, revisa la página Attack Events a diario y pasa a Balanced una vez que hayas ajustado los falsos positivos.
• En el plan Lite, configura la integración de notificaciones con Discord o Telegram para que las alertas de ataque te lleguen fuera del panel.
• Programa una ventana de mantenimiento mensual. Antes de actualizar, haz una copia de seguridad de los datos y de la configuración del entorno de SafeLine, lee las notas de la versión actual, y usa el procedimiento de actualización compatible con tu versión instalada. No dependas únicamente de docker compose pull seguido de docker compose up -d, porque la definición de Compose o las variables de entorno necesarias pueden cambiar entre versiones. Los usuarios del despliegue de un clic de Cloudzy deberían trabajar desde /opt/safeline y seguir las instrucciones de la imagen del marketplace.
• Suscríbete a la página de versiones de SafeLine para recibir notificaciones de parches de seguridad, y al repositorio del proyecto para el seguimiento de incidencias.

Si todavía no tienes un VPS para este despliegue, SafeLine está disponible como despliegue de un clic en El marketplace de Cloudzy. Un plan con 4 GB RAM ofrece el margen práctico recomendado en esta guía; vuelve a consultar la tabla de precios actual en Cloudzy en el momento de la publicación, ya que las especificaciones de los planes pueden cambiar. La imagen de un clic utiliza /opt/safeline y /opt/safeline/docker-compose.yml, así que las instrucciones de arquitectura y del panel se aplican, pero los /data/safeline comandos de esta guía no se aplican de forma idéntica.

Preguntas frecuentes

¿SafeLine WAF reemplaza a Nginx Proxy Manager, o ejecuto ambos?

SafeLine puede reemplazar a Nginx Proxy Manager cuando se despliega como único proxy inverso. Sin embargo, no tiene por qué reemplazar a NPM. Una configuración habitual mantiene NPM al frente para SSL y enrutamiento y coloca SafeLine detrás como una capa de seguridad dedicada. Ambos enfoques funcionan; la elección depende de si quieres una herramienta que haga ambos trabajos o dos herramientas que hagan bien cada una su trabajo.

¿El plan gratuito es suficiente para un solo sitio WordPress o un SaaS pequeño?

Sí, en cuanto a protección. El plan Personal gratuito incluye el motor de detección semántica, la limitación de tasa, el desafío CAPTCHA contra bots y el cifrado dinámico de HTML/JS, que son defensas fundamentales para un solo sitio. Los planes de pago añaden funciones operativas como geobloqueo, exportación de registros de ataques, notificaciones externas, límites de aplicaciones más altos, una detección más potente y balanceo de carga. Que un plan de pago sea necesario depende de las funciones requeridas y del número de aplicaciones, no solo del volumen de tráfico.

¿SafeLine funciona en un VPS con 1 GB RAM?

El mínimo oficial de SafeLine es 1 GB RAM. Eso puede bastar para pruebas o una carga de trabajo muy ligera, pero la capacidad de producción depende del tráfico, las funciones habilitadas y la retención de registros. Para un despliegue de producción pequeño, 2 vCPU y 4 GB RAM es un punto de partida conservador; monitoriza el uso de memoria y escala a partir de la carga medida.

¿Por qué ARM64 requiere una licencia de pago?

El documentación de despliegue oficial de SafeLine indica que los despliegues en ARM requieren una licencia Pro y que la edición Personal no es compatible con ARM. Si quieres la edición Personal, elige un VPS x86_64; si necesitas ARM, planifica una licencia Pro.

¿Qué recibe Chaitin Tech de mi instancia de SafeLine?

Los datos salientes exactos pueden variar según la versión y las funciones habilitadas. Las notas de la versión actual de CE mencionan el intercambio de inteligencia de amenazas (Threat Intelligence Sharing), y la versión instalada también puede exponer UEP u otros controles de intercambio. Revisa esos ajustes y las notas de la versión que tengas instalada, luego valida la salida de tráfico a nivel de red. Los contenedores locales de SafeLine gestionan los datos de la aplicación, pero ese hecho por sí solo no demuestra que rechazar UEP detenga todas las solicitudes salientes.