Cómo alojar SearXNG en 2026: Search API, rate limits y TLS
Aloja SearXNG con los puertos correctos, almacenamiento persistente, HTTPS, secretos, backups y comprobaciones de actualización. Aprende a solucionar los casos en los que los motores bloquean la IP del servidor.
La mayoría de las notas de instalación de SearXNG terminan en la primera carga de página. Es demasiado pronto: los motores pueden bloquear la IP del servidor o algunos formatos pueden omitir json para los clientes de API. Una prueba de producción útil es más exigente: enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba.
El papel de SearXNG es sencillo: un metasearch engine y Search API centrados en la privacidad. Sus límites operativos abarcan más que el proceso web, por lo que hay que especificar la dependencia, el estado almacenado y la ruta pública antes de que lleguen datos reales.
Define primero qué significa tener SearXNG listo
No dejes que la imagen de SearXNG elija accidentalmente la arquitectura de producción. La imagen proporciona un proceso en 8080; el almacenamiento, el routing y los requisitos externos siguen necesitando ciclos de vida definidos de forma deliberada. El contrato de red de SearXNG es Redis o Valkey cuando están habilitadas las funciones de limiter y detección de bots. Mantén los endpoints privados en DNS interno, permite solo las llamadas salientes necesarias y asigna a SearXNG una credencial de servicio con permisos limitados.
El despliegue está listo para pruebas más profundas cuando puede enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba. Sigue la transacción en los logs y observa la latencia de los motores upstream, las consultas simultáneas, el parsing de resultados y los bloqueos aplicados a la IP del servidor. Estas observaciones muestran si la topología actual aísla el componente adecuado.
Separa los containers reemplazables de los datos persistentes
Crea un recovery manifest para SearXNG: settings.yml, la configuración del limiter y cualquier plugin local. Monta /etc/searxng antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el container para demostrar que esa ruta es realmente persistente. Comprueba ahora los permisos y el espacio libre, porque una ruta montada pero sin permisos de escritura se comporta como si no hubiera persistencia.
Haz backups en un failure domain separado del servidor en ejecución. Recrea SearXNG desde su imagen fijada y verifica que vuelven los engines personalizados, los formatos, las reglas del limiter y la configuración del proxy, y que una consulta conocida produce resultados de varios motores. La guía de persistent volumes ayuda a convertir este ejercicio en una política de snapshots y retención.
Cierra el acceso temporal de configuración
Las credenciales de bootstrap son temporales; el modelo de confianza es permanente. Con SearXNG, presta atención a no publicar el secret_key de ejemplo ni desactivar los rate controls en un endpoint público; mantén una secret key no predeterminada, habilita los controles contra abusos y expón JSON solo cuando un agente o una aplicación lo necesite.
Trata SEARXNG_SECRET según su función en SearXNG: mantén los valores sensibles fuera de Git, documenta los efectos de la rotación y no sustituyas nunca un ejemplo público en producción. Ejecuta la imagen sin capabilities de Linux innecesarias y expón únicamente la ruta pública de la aplicación. Mantén visible la actividad de administración sin registrar valores secretos.
Registra un despliegue de SearXNG validado
Convierte el smoke test de SearXNG en un comando de release repetible o en un runbook breve. Su salida debe demostrar este resultado: enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba. Registra con el resultado la versión de la aplicación, el digest del container, el hostname de la ruta y el identificador de los datos de prueba.
Ejecuta la misma comprobación después de sustituir un container de rutina y después de restaurar settings.yml, la configuración del limiter y cualquier plugin local en otro entorno. La restauración ha funcionado cuando vuelven los engines personalizados, los formatos, las reglas del limiter y la configuración del proxy, y una consulta conocida produce resultados de varios motores. Compara los tiempos y el consumo relacionados con la latencia de los motores upstream, las consultas simultáneas, el parsing de resultados y los bloqueos aplicados a la IP del servidor; un cambio importante merece investigación aunque la acción final siga pasando.
Después, prueba un fallo seguro: deniega temporalmente al test identity el acceso a Redis o Valkey cuando estén habilitadas las funciones de limiter y detección de bots. Confirma que SearXNG muestra el fallo y vuelve a la normalidad sin ediciones manuales destructivas. Conserva únicamente el fragmento de log necesario y con los datos sensibles redactados. Esta gate de cuatro partes cubre el arranque, la persistencia, la recuperación y la gestión de fallos.
Ejecuta la primera instancia con forma de producción
Usa el container como un runtime reemplazable, no como la ubicación de la verdad.
docker run -d \
--name searxng \
--restart unless-stopped \
-p 127.0.0.1:8080:8080 \
-v searxng-data:/etc/searxng \
-e SEARXNG_SECRET=replace-with-a-long-random-value \
searxng/searxng:latest
Añade la configuración de conexión revisada para Redis o Valkey cuando estén habilitadas las funciones de limiter y detección de bots; usa nombres privados para los servicios privados. Inspecciona el usuario del container, las rutas con permisos de escritura y el listener enlazado antes de exponerlo. Ejecuta la acción completa —enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba— y guarda la referencia exacta de la imagen que produjo el resultado.
Evita que el éxito del proxy oculte un fallo de la aplicación
Expón un único hostname HTTPS para SearXNG y mantén privado el puerto 8080 sin proxy. Configura server base_url y trusted proxy headers para HTTPS. Así evitarás que los navegadores y los clientes de API conozcan dos direcciones que compiten entre sí.
Desde un cliente limpio, ejecuta la transacción validada e inspecciona la primera request que falle. Usa la guía de custom domains cuando el DNS o TLS no sean correctos. Trata “los motores bloquean la IP del servidor o los formatos omiten json para los clientes de API” como un diagnóstico independiente de la aplicación una vez validada la ruta.
Logs que responden a la siguiente pregunta
La primera métrica operativa útil para SearXNG es si puede enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba. Combínala con señales de saturación relativas a la latencia de los motores upstream, las consultas simultáneas, el parsing de resultados y los bloqueos aplicados a la IP del servidor. Un probe que compruebe solo el proceso no debería llamar a dependencias costosas ni reiniciar el container porque un upstream no esté disponible temporalmente.
Trata las actualizaciones como cambios de datos porque la sintaxis de settings, las definiciones de engines y el comportamiento del limiter pueden cambiar; por eso, despliega los cambios de configuración y de imagen como una única revisión. Fija las versiones, haz ensayos sobre un estado restaurado y conserva la imagen anterior hasta que el rollback siga siendo válido. Cuando los motores bloqueen la IP del servidor o los formatos omitan json para los clientes de API, conserva los logs anteriores al reinicio; normalmente contienen el mensaje causal.
Integra SearXNG en el ciclo de vida de Dockup
La capa de plataforma para SearXNG consta del puerto 8080, el ingress, TLS, la configuración del runtime, el almacenamiento y la conectividad con las dependencias. Dockup puede reproducir estas piezas para su propia infraestructura o para un servidor que conecte el cliente.
Después, el operador completa la capa de producto: configura server base_url y trusted proxy headers para HTTPS; aplica esta regla de acceso —mantener una secret key no predeterminada, habilitar los controles contra abusos y exponer JSON solo cuando un agente o una aplicación lo necesite—; y ejecuta “enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba”. Registrar esa prueba junto con el despliegue evita confundir el aprovisionamiento automatizado con la disponibilidad de la aplicación.
Preguntas frecuentes
¿Qué necesita SearXNG para un despliegue de producción?
Dirige el container de SearXNG en el puerto 8080 a través de un único origen HTTPS. El requisito de red de soporte es Redis o Valkey cuando están habilitadas las funciones de limiter y detección de bots. No consideres que SearXNG está listo hasta poder enviar búsquedas HTML y JSON, confirmar que varios motores aportan resultados y activar el limiter configurado desde un cliente de prueba.
¿Qué datos de SearXNG deben incluirse en un backup?
Haz persistente /etc/searxng e incluye settings.yml, la configuración del limiter y cualquier plugin local en el mismo recovery manifest. Una restauración limpia de SearXNG solo es válida cuando vuelven los engines personalizados, los formatos, las reglas del limiter y la configuración del proxy, y una consulta conocida produce resultados de varios motores.
¿SearXNG necesita HTTPS detrás de un reverse proxy?
Usa HTTPS para el origen público de SearXNG y mantén el puerto 8080 en la ruta interna. Aplica correctamente la configuración de SearXNG: configura server base_url y trusted proxy headers para HTTPS. En SearXNG, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente que depende del origen.
¿Cómo debe probarse una actualización de SearXNG?
Restaura el estado actual de SearXNG en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque la sintaxis de settings, las definiciones de engines y el comportamiento del limiter pueden cambiar; por eso, despliega los cambios de configuración y de imagen como una única revisión. Conserva la imagen anterior de SearXNG hasta comprender los límites de la migración de datos y del rollback.