Cómo alojar ConvertX por tu cuenta en 2026: cargas, secretos JWT y límites de recursos

Hay dos versiones de «ejecutar ConvertX»: que exista un contenedor o que el servicio complete su trabajo real. Solo importa la segunda. En este caso, la prueba consiste en cargar varios formatos representativos, convertir cada uno, descargar los resultados y comparar hashes o propiedades multimedia cuando el resultado sea determinista.

ConvertX cumple esta función: es un servicio de conversión de archivos basado en el navegador. El despliegue debe conservar los elementos que hacen posible ese comportamiento; un puerto, un volumen y un certificado son entradas, no el resultado.

Elige la topología mínima viable para ConvertX

Empieza por el espacio de nombres de red de ConvertX: su listener web está en el puerto 3000, no en un puerto del host copiado de un tutorial para portátiles. El requisito del entorno de ejecución local es contar con CPU, memoria y disco temporal adecuados para los conversores seleccionados. Documenta la capacidad esperada, la propiedad y el modo de fallo en lugar de dejar estos aspectos en los valores predeterminados de la imagen.

Una vez satisfecho el requisito, ejecuta el escenario completo: carga varios formatos representativos, convierte cada uno, descarga los resultados y compara hashes o propiedades multimedia cuando el resultado sea determinista. Registra los logs y las mediciones de CPU, memoria, disco temporal, tamaño de archivo y los binarios de conversión invocados por cada par de formatos. Estas evidencias se convierten en la primera arquitectura conocida como válida y permiten probar posteriores cambios entre el cómputo de Dockup y un servidor conectado.

Mantén separadas las URL internas y externas

Evita usar orígenes públicos temporales y permanentes para ConvertX. En su lugar, publica la interfaz mediante HTTPS con límites de carga definidos, apunta el nombre DNS elegido a la ruta de la plataforma y usa el proxy únicamente hacia el puerto 3000.

Prueba esta operación desde fuera del host: carga varios formatos representativos, convierte cada uno, descarga los resultados y compara hashes o propiedades multimedia cuando el resultado sea determinista. Si falla el ingress, la guía para solucionar errores 502 explica los errores relacionados con los puertos y los listeners. Si ConvertX recibe la solicitud, pero falta un binario de conversión o el proxy rechaza una carga grande, las evidencias apuntan ya a un problema más allá del proxy.

Configuración del contenedor que conviene revisar

Inicia ConvertX de forma que la ruta permanezca privada hasta completar el arranque inicial.

docker run -d \
  --name convertx \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v convertx-data:/app/data \
  -e JWT_SECRET=replace-with-a-long-random-value \
  ghcr.io/c4illin/convertx:latest

Si el proceso entra en un bucle, compara el usuario esperado por la imagen con el propietario de cada ruta montada. Si permanece activo, prueba localmente el puerto 3000 y pasa directamente al flujo de trabajo: carga varios formatos representativos, convierte cada uno, descarga los resultados y compara hashes o propiedades multimedia cuando el resultado sea determinista. Fija la versión de la imagen solo después de superar esta comprobación de extremo a extremo y registra la configuración exacta junto al servicio.

Ensaya el cambio de ConvertX más arriesgado

Una comprobación de estado inactiva dice muy poco sobre ConvertX. Supervisa la CPU, la memoria, el disco temporal, el tamaño de archivo y los binarios de conversión invocados por cada par de formatos. Después, configura alertas para el síntoma que experimentan los usuarios: el fallo de la operación «cargar varios formatos representativos, convertir cada uno, descargar los resultados y comparar hashes o propiedades multimedia cuando el resultado sea determinista». Mantén el liveness local y económico; permite que el readiness informe de migraciones o inicializaciones sin provocar una tormenta de reinicios.

El área de actualización de mayor riesgo es que las versiones de la imagen pueden añadir o eliminar conversores, así que prueba la matriz exacta de formatos de la que dependen los usuarios. Lee las notas de la versión, crea una instantánea del estado, despliega la versión objetivo sobre una copia restaurada y repite la prueba de aceptación. Si falta un binario de conversión o el proxy rechaza una carga grande, relaciona la solicitud del cliente con el primer log relevante de la aplicación en lugar de borrar el estado o añadir redirecciones a ciegas.

Cinco comprobaciones más sólidas que la salud del contenedor

No conviertas el tráfico del primer usuario en la prueba de aceptación de ConvertX. Prepara datos de ejemplo inocuos y ejecuta la operación completa «cargar varios formatos representativos, convertir cada uno, descargar los resultados y comparar hashes o propiedades multimedia cuando el resultado sea determinista». Anota la URL pública exacta, el resultado, la referencia de la imagen y el intervalo de logs asociado a la ejecución.

Sustituye el contenedor y repite la prueba sin reconstruir los datos. Después, recupera el servicio en un host vacío; la condición de recuperación es que las cuentas y la configuración vuelvan a estar disponibles y que la matriz fija de formatos se complete dentro de los límites establecidos. Observa la CPU, la memoria, el disco temporal, el tamaño de archivo y los binarios de conversión invocados por cada par de formatos en cada pasada, y define una alerta en torno a la degradación de la transacción, no de las métricas del contenedor inactivo.

Una comprobación final debe fallar a propósito: envía una entrada inocua cercana al límite de recursos o de formatos asociado a este escenario: falta un binario de conversión o el proxy rechaza una carga grande. Verifica que el mensaje resultante de ConvertX identifique el límite relevante en lugar de provocar el borrado de datos o un reinicio interminable. Restablece la condición válida y confirma que la misma transacción de ejemplo se completa correctamente. Incluye este breve ejercicio en la checklist de versiones.

Encuentra cada byte persistente de ConvertX

El conjunto que debe recuperarse incluye los datos de la aplicación, las cuentas y cualquier configuración de conversión conservada. Monta /app/data antes del arranque inicial, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Un volumen protege los datos frente a la sustitución del contenedor, pero no frente a la pérdida del host, el borrado accidental o la corrupción a nivel de aplicación.

Crea copias de seguridad que entiendan el origen de los datos: utiliza volcados lógicos para bases de datos activas cuando sea necesario y copia archivos únicamente desde un estado coherente. Conserva una copia cifrada fuera del host de ConvertX. El criterio de aceptación de una restauración debe ser específico: las cuentas y la configuración vuelven a estar disponibles y la matriz fija de formatos se completa dentro de los límites establecidos. La guía sobre copias de seguridad cuya restauración se ha probado explica por qué el éxito de un job, por sí solo, no es suficiente.

Reduce la autoridad de la que dispone ConvertX

Después del primer inicio de sesión, revisa qué puede hacer un visitante anónimo, un usuario normal y un administrador. El fallo de ConvertX que debes evitar es utilizar un secreto JWT de ejemplo u ofrecer conversiones públicas sin restricciones. La política prevista consiste en utilizar un secreto JWT real, exigir el inicio de sesión y limitar las cargas antes de aceptar archivos no confiables desde internet.

Genera JWT_SECRET como un valor aleatorio largo; rotarlo normalmente invalida las sesiones o los tokens, así que planifica el impacto para los usuarios en lugar de considerarlo una migración de cifrado. Mantén separadas las cuentas de dependencias y las cuentas humanas, deniega el tráfico de salida que no se utilice cuando sea práctico y limita el trabajo condicionado por la CPU, la memoria, el disco temporal, el tamaño de archivo y los binarios de conversión invocados por cada par de formatos.

Despliega ConvertX en Dockup sin perder sus límites

Dockup elimina el trabajo manual de reverse proxy y gestión del ciclo de vida alrededor de ConvertX. El servicio recibe una ruta HTTPS estable hacia el puerto 3000, configuración inyectada y almacenamiento persistente durante las sustituciones. Un servidor de cliente conectado sigue el mismo modelo que el cómputo alojado en Dockup.

Después del lanzamiento, satisface el contrato de la aplicación: publica la interfaz mediante HTTPS con límites de carga definidos, confirma el requisito local —CPU, memoria y disco temporal adecuados para los conversores seleccionados— y ejecuta esta prueba: carga varios formatos representativos, convierte cada uno, descarga los resultados y compara hashes o propiedades multimedia cuando el resultado sea determinista. Así, la experiencia de un solo clic sigue siendo útil sin ocultar los detalles que hacen que ConvertX sea recuperable y seguro.

Preguntas frecuentes

¿Qué necesita ConvertX para un despliegue de producción?

Enruta el contenedor de ConvertX en el puerto 3000 a través de un único origen HTTPS. El requisito del entorno de ejecución local es contar con CPU, memoria y disco temporal adecuados para los conversores seleccionados. No consideres ConvertX listo hasta que puedas cargar varios formatos representativos, convertir cada uno, descargar los resultados y comparar hashes o propiedades multimedia cuando el resultado sea determinista.

¿Qué datos de ConvertX deben incluirse en una copia de seguridad?

Conserva /app/data e incluye los datos de la aplicación, las cuentas y cualquier configuración de conversión conservada en el mismo manifiesto de recuperación. Una restauración limpia de ConvertX solo es válida cuando las cuentas y la configuración vuelven a estar disponibles y la matriz fija de formatos se completa dentro de los límites establecidos.

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

Usa HTTPS para el origen público de ConvertX y mantén el puerto 3000 en la ruta interna. Aplica correctamente la configuración de ConvertX: publica la interfaz mediante HTTPS con límites de carga definidos. En ConvertX, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente que depende del origen.

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

Restaura el estado actual de ConvertX en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las versiones de la imagen pueden añadir o eliminar conversores, así que prueba la matriz exacta de formatos de la que dependen los usuarios. Conserva la imagen anterior de ConvertX hasta comprender los límites de migración de datos y de rollback.