Cómo alojar CyberChef por tu cuenta en 2026: acceso seguro, hosting sin estado y actualizaciones

La demo más sencilla de CyberChef demuestra que un proceso escucha en el puerto 80. En producción hace falta evidencia más sólida. Debe superar este escenario incluso después de reemplazar el contenedor: crear una recipe de varios pasos, exportarla, procesar un archivo representativo y confirmar que el hash de salida coincide con un valor conocido.

CyberChef se despliega con un objetivo claro: ofrecer un workbench en el navegador para encoding, decoding, parsing y cryptography. Su trampa de despliegue más habitual es que las operaciones grandes agotan la memoria del navegador aunque el servidor esté sano, por lo que el tratamiento de la URL pública y el estado duradero requieren la misma atención que el arranque de la imagen.

Elige la topología mínima viable para CyberChef

Un diagrama útil de CyberChef muestra la ruta pública, el puerto privado 80, el límite del estado y todos los requisitos de soporte. Indica qué flechas transportan credenciales y cuáles corresponden al tráfico normal de los usuarios. La build estándar de CyberChef no necesita una base de datos ni un servicio de runtime persistente independiente. Mantén el contenedor web reemplazable y coloca cualquier componente futuro de autenticación, colaboración o almacenamiento detrás de un límite documentado por separado.

Demuestra el diagrama con una acción real: crea una recipe de varios pasos, expórtala, procesa un archivo representativo y confirma que el hash de salida coincide con un valor conocido. La presión más probable procede de la memoria del navegador y la CPU necesarias para recipes grandes, no del cómputo en el lado del contenedor en el despliegue estático estándar; monitoriza esa ruta en lugar de tratar todas las solicitudes HTTP como equivalentes.

Ejecuta la primera instancia con forma de producción

Usa el contenedor como un runtime reemplazable, no como la ubicación de la información de referencia.

docker run -d \
  --name cyberchef \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  ghcr.io/gchq/cyberchef:latest

Confirma el requisito local antes de exponerlo: la build estándar del lado del cliente no necesita una base de datos. Inspecciona el usuario del contenedor, las rutas con permisos de escritura y el listener asociado antes de exponerlo. Ejecuta la acción completa —crea una recipe de varios pasos, expórtala, procesa un archivo representativo y confirma que el hash de salida coincide con un valor conocido— y guarda la referencia exacta de la imagen que produjo el resultado.

Prueba CyberChef desde fuera del servidor

Publica la interfaz estática en un origen HTTPS de confianza. Envía el hostname elegido al puerto 80 del contenedor, reenvía el host original y el esquema HTTPS, y evita publicar un segundo origen directo.

Prueba CyberChef desde un cliente externo limpio. Separa los fallos de ingress del límite conocido de la aplicación: las operaciones grandes agotan la memoria del navegador aunque el servidor esté sano. Un error de certificado, DNS o 502 pertenece al routing; una solicitud que llega a CyberChef y falla después pertenece al estado de la aplicación, la capacidad o alguno de sus requisitos de soporte. La guía de TLS para dominios personalizados cubre el primer grupo.

Encuentra cada byte duradero de CyberChef

El contenedor estándar de CyberChef no tiene ningún mount obligatorio para los datos de la aplicación. Aun así, su conjunto de recuperación debe estar definido explícitamente: no hay datos de aplicación; conserva la configuración del despliegue y el pin de la imagen. No crees un volumen vacío solo para que el despliegue parezca stateful; conserva la referencia exacta de la imagen y la configuración revisada.

Reconstruye CyberChef en un host vacío y ejecuta la transacción de aceptación. La recuperación es correcta cuando se puede recrear la build estática fijada y una recipe exportada produce la misma salida conocida. Cualquier base de datos o servicio de colaboración conectado debe seguir su propio plan de backup consistente con la aplicación, mientras que el contenedor web reemplazable se recrea a partir del código. La guía para pasar de Git a producción describe ese límite reproducible.

Conserva un checksum o digest de la imagen conocida como válida y vuelve a probar después de las actualizaciones. En un servicio stateless, una reconstrucción correcta es la prueba de restore; para el estado externo, el runbook de CyberChef debe enlazar con el responsable y el procedimiento de recuperación independientes.

Protege la parte valiosa de CyberChef

No añadas un secret de entorno ficticio solo para que CyberChef parezca más seguro. La preocupación importante es procesar material sensible con una imagen modificada o no confiable, así que publica únicamente una imagen oficial o una build reproducible cuando los operadores vayan a pegar credenciales, capturas o evidencias codificadas.

Restringe la ruta pública cuando sea necesario, verifica el digest de la imagen y ejecuta el contenedor sin mounts del host ni privilegios que no necesite. Aplica límites basados en la memoria del navegador y la CPU para recipes grandes, no en el cómputo del lado del contenedor en el despliegue estático estándar. Los logs deben registrar fallos y tiempos sin conservar los datos sensibles procesados por CyberChef.

Diagnostica un CyberChef que parece estar sano

Mide la memoria del navegador y la CPU para recipes grandes, no el cómputo del lado del contenedor en el despliegue estático estándar, mientras ejecutas esta transacción de regresión: crea una recipe de varios pasos, expórtala, procesa un archivo representativo y confirma que el hash de salida coincide con un valor conocido. Mantén el liveness probe ligero; el trabajo de conversión o del lado del navegador debe pertenecer a un release check independiente para que una muestra pesada no provoque un restart loop.

El riesgo de una actualización es que las operaciones de las recipes de CyberChef y las librerías incluidas pueden cambiar la salida o la compatibilidad, por lo que la build fijada necesita un regression test. Ejecuta el digest candidato junto a la imagen actual, proporciona a ambas las mismas entradas conocidas y compara las salidas, los headers y los tiempos. Si las operaciones grandes agotan la memoria del navegador aunque el servidor esté sano, conserva la solicitud fallida y la referencia de la imagen antes de cambiar la ruta.

Convierte el smoke test de CyberChef en un release check

El registro del release de CyberChef necesita datos concretos, no un simple «parece correcto». Guarda el digest de imagen seleccionado, el checksum de la configuración, el hostname público y un resultado con timestamp para estas acciones: crear una recipe de varios pasos, exportarla, procesar un archivo representativo y confirmar que el hash de salida coincide con un valor conocido. Usa datos de muestra que no sean de producción para que la comprobación pueda ejecutarse después de cada despliegue.

Demuestra por separado dos eventos del ciclo de vida. El reemplazo de un contenedor debe conservar el funcionamiento normal; una recuperación limpia debe demostrar que se puede recrear la build estática fijada y que una recipe exportada produce la misma salida conocida. Mientras se ejecutan las comprobaciones, mide la memoria del navegador y la CPU para recipes grandes, no el cómputo del lado del contenedor en el despliegue estático estándar, y conserva el resultado como el envelope esperado para esta versión.

Prueba también una condición denegada o no válida: envía una entrada inofensiva cercana al límite de recursos o formato asociado a este límite: las operaciones grandes agotan la memoria del navegador aunque el servidor esté sano. CyberChef debe fallar de forma diagnosticable y no sobrescribir un estado correcto. Restablece la condición válida, vuelve a ejecutar la muestra y adjunta los logs relevantes con los datos sensibles ocultos. Estos artefactos proporcionan evidencias concretas para una futura decisión de rollback.

Traslada el trabajo de infraestructura repetible a Dockup

Para CyberChef stateless, el trabajo de Dockup es limitado y útil: iniciar la imagen fijada, mantener privado el puerto 80, asociar la ruta HTTPS y reemplazar el contenedor sin inventar almacenamiento. El despliegue puede dirigirse a la infraestructura de Dockup o a un servidor asociado del cliente.

Completa la configuración de la aplicación: publica la interfaz estática en un origen HTTPS de confianza. Dockup debe conservar la configuración del runtime de CyberChef mientras el operador confirma este requisito local: la build estándar del lado del cliente no necesita una base de datos. Ejecuta esta acción de aceptación: crea una recipe de varios pasos, expórtala, procesa un archivo representativo y confirma que el hash de salida coincide con un valor conocido. La autenticación opcional o los servicios externos deben representarse como configuración y dependencias independientes para que el despliegue siga siendo preciso.

Preguntas frecuentes

¿Qué necesita CyberChef para un despliegue en producción?

Enruta el contenedor de CyberChef en el puerto 80 a través de un único origen HTTPS. La build estándar de CyberChef no necesita una base de datos ni un servicio de runtime persistente independiente. No consideres CyberChef listo hasta que puedas crear una recipe de varios pasos, exportarla, procesar un archivo representativo y confirmar que el hash de salida coincide con un valor conocido.

¿Qué datos de CyberChef deben incluirse en un backup?

La imagen estándar de CyberChef no tiene ningún mount obligatorio para los datos de la aplicación. Conserva su configuración de despliegue y haz backup por separado de cualquier estado conectado; la recuperación es correcta cuando se puede recrear la build estática fijada y una recipe exportada produce la misma salida conocida.

¿CyberChef necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de CyberChef y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de CyberChef: publica la interfaz estática en un origen HTTPS de confianza. En CyberChef, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de CyberChef?

Despliega la imagen candidata de CyberChef junto a la actual y repite la transacción de aceptación con una entrada conocida. Presta especial atención porque las operaciones de las recipes de CyberChef y las librerías incluidas pueden cambiar la salida o la compatibilidad, por lo que la build fijada necesita un regression test. El contenedor estándar no tiene migración de datos, así que conserva el digest anterior hasta que se superen las comprobaciones de salida y compatibilidad.