Aloja tu propio conversor de archivos con HRConvert2

Por qué alojar un conversor de archivos

Un conversor de archivos autoalojado mantiene el archivo en su propio disco. Esa es la razón principal para ejecutar uno. Un sitio de conversión gratuito recibe la carga y no ofrece ninguna forma de saber qué ocurre con ella después. Cuando el archivo es un contrato firmado de un cliente o un historial médico escaneado, la propia carga ya constituye el incidente. HRConvert2 es un servidor de conversión de archivos escrito en PHP y distribuido bajo la licencia GPLv3. La versión 3.7.4 se publicó el 18 August 2026 y el proyecto afirma admitir 488 formatos.

No usa base de datos, cuentas ni cookies. Cada usuario tiene un directorio temporal. Cada conversión la realiza una herramienta local de línea de comandos: LibreOffice para documentos, FFmpeg para audio y vídeo, ImageMagick para imágenes, Tesseract para el reconocimiento óptico de caracteres (OCR) y muchas otras herramientas pequeñas para el resto. HRConvert2 proporciona la página de carga, la canalización de procesamiento y la limpieza asociada.

Convierte un archivo de un formato a otro. No es una suite ofimática en el navegador. Si necesita que varias personas editen documentos en una pestaña, compare OnlyOffice y Collabora autoalojados. Tampoco es almacenamiento. El resultado convertido debe eliminarse. Si los archivos deben conservarse en algún lugar, esa tarea corresponde a un gestor de archivos autoalojado.

Lo que necesita

Debian o Ubuntu, Apache 2.4, PHP 8 o posterior y bubblewrap. Bubblewrap (bwrap) es el sandbox y no es opcional: un servidor que no puede crear un sandbox rechaza la conversión en lugar de ejecutarla sin él. El README del proyecto indica que una Raspberry Pi Model B+ es suficiente, lo que es cierto para la parte de PHP. Los binarios del conversor determinan los requisitos reales de hardware, que se explican más adelante.

Hay dos formas de empezar. La imagen de Docker funciona de inmediato. La instalación de Apache y PHP requiere una tarde y muestra exactamente qué hay instalado en el equipo.

Ejecutarlo esta noche con Docker

La imagen incluye todos los binarios de conversión, por lo que es grande: unos 3 GB a fecha de agosto de 2026. Compruebe el espacio libre en disco antes de descargarla.

Las etiquetas son importantes en este caso. La etiqueta más reciente publicada en Docker Hub a fecha de 17 August 2026 es v3.7.2, mientras que la versión más reciente de GitHub es v3.7.4. La etiqueta latest puede cambiar sin aviso, y esta aplicación tiene una superficie de análisis grande, por lo que debe fijar una versión y actualizarla de forma planificada.

docker pull zelon88/hrconvert2:v3.7.2
docker run -d --name hrconvert2 \
  -p 127.0.0.1:8080:80 \
  --security-opt seccomp=unconfined \
  zelon88/hrconvert2:v3.7.2

docker ps
curl -I http://127.0.0.1:8080/

Un contenedor en buen estado permanece en el estado Up y curl devuelve HTTP/1.1 200 OK. Un contenedor que se reinicia continuamente tiene un problema durante el arranque, así que revise docker logs hrconvert2 antes de cambiar cualquier otra cosa.

Dos flags son especialmente importantes. -p 127.0.0.1:8080:80 publica el puerto sólo en loopback, por lo que ninguna conexión llega al conversor hasta que coloque deliberadamente un proxy delante. El ejemplo del proyecto asigna -p 8080:80 -p 8443:443, que escucha en todas las interfaces, incluida la pública. --security-opt seccomp=unconfined es necesario porque bubblewrap crea su sandbox mediante llamadas al sistema de espacios de nombres de usuario y de montaje que el perfil seccomp predeterminado de Docker bloquea. Sin ese flag, las conversiones fallan y la aplicación indica el motivo: A sandbox blocks the required syscalls unless it was started with the correct options.

Ese flag implica una compensación real. Relaja el filtro de llamadas al sistema del contenedor para que la aplicación pueda crear dentro de él un sandbox más restrictivo. Los dos ajustes que determinan el comportamiento son $RequireSandbox y $RequireSandboxOnDocker en Resources/config.php, cuyos valores predeterminados son TRUE y FALSE. Como el requisito de Docker está desactivado de forma predeterminada, un contenedor sin el flag de seccomp puede convertir sin ningún sandbox. Cuando el flag esté configurado, establezca $RequireSandboxOnDocker = TRUE; y recuperará el comportamiento de rechazo dentro del contenedor.

Si Docker es nuevo en esta máquina, configure primero el daemon. Ejecutar Docker en un VPS explica la instalación, el controlador de almacenamiento y la forma en que Docker escribe sus propias reglas del firewall.

Instalarlo con Apache y PHP

El archivo Documentation/INSTALLATION_INSTRUCTIONS.txt del repositorio es la referencia principal y contiene nueve pasos. Esta es su estructura. Empiece por el servidor web, el lenguaje y el sandbox:

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-all-dev php8.3-zip php8.3-gd bubblewrap

Los nombres de php8.3-* corresponden a Ubuntu 24.04. Ejecute php -v y use el prefijo que corresponda a su versión, porque esos nombres de paquetes cambian con cada versión de PHP y el incorrecto produce Unable to locate package.

A continuación, los conversores. Esto cubre documentos, imágenes, audio, vídeo y OCR, que es la mayor parte de las conversiones habituales:

sudo apt install -y imagemagick ffmpeg libreoffice-common libreoffice-java-common \
  default-jre ghostscript poppler-utils libgxps-utils tesseract-ocr inkscape \
  xvfb clamav curl tar libxcb-cursor0

Los formatos de archivo comprimido, los modelos 3D, los ebooks y las imágenes ISO arrancables necesitan más paquetes. Algunos están en el componente multiverse de Ubuntu. Los pasos 3 y 5 de las instrucciones oficiales incluyen la lista completa en el orden correcto. Hay dos dependencias que no son paquetes apt: el repositorio proporciona Documentation/Build/ffmpeg-build.sh y Documentation/Build/build-imagemagick-v7.sh para quienes necesitan codificadores o ImageMagick 7, que Ubuntu no empaqueta. La compatibilidad con ebooks procede del instalador propio de calibre, que las instrucciones muestran en una sola línea:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdin

Es un script del proveedor que se canaliza a un shell como root. Es el método del proyecto original y es opcional: si lo omite, sólo perderá la conversión de ebooks.

A continuación, los límites de PHP. Las conversiones son lentas y los archivos son grandes, por lo que los valores predeterminados son demasiado bajos. El proyecto establece estos valores en php.ini:

max_execution_time = 1200
max_input_time = 90
memory_limit = 512M
post_max_size = 5000M
upload_max_filesize = 5000M
max_file_uploads = 100
display_errors = Off
zlib.output_compression = On

Esos valores presuponen una máquina con recursos suficientes. Redúzcalos antes de acercarse a un VPS pequeño, porque upload_max_filesize = 5000M con max_file_uploads = 100 describe una sola solicitud que puede escribir mucho más de lo que admite un disco de 40 GB. Reinicie Apache y confirme lo que PHP ha cargado realmente:

sudo service apache2 restart
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Ahora, el directorio de trabajo. $ConvertLoc en Resources/config.php lo especifica, y el valor predeterminado es /DATA/HRConvert2. El usuario del servidor web debe ser su propietario:

sudo mkdir -p /DATA/HRConvert2
sudo chmod -R 0755 /DATA/HRConvert2
sudo chown -R www-data:www-data /DATA/HRConvert2

Descomprima la versión en el document root de Apache. La estructura predeterminada la coloca en una carpeta HRProprietary/HRConvert2, y $InstLoc en Resources/config.php debe indicar la ubicación donde la haya instalado realmente. Después, ejecute el diagnóstico integrado. Es la forma más rápida de detectar una dependencia ausente antes de que lo haga un usuario:

sudo php /path/to/HRConvert2/convertCore.php -v

-v comprueba toda la instalación: versiones del núcleo, dependencias, estado del sandbox y paquetes de idioma. Las conversiones de archivos no son compatibles desde la línea de comandos, por lo que este conjunto de argumentos sólo sirve para tareas administrativas.

¿Por qué falla cada conversión en una instalación nueva de Ubuntu 24.04?

La causa es el sandbox, y este es el problema inicial más frecuente. Ubuntu 24.04 y Debian 12 restringen de forma predeterminada los espacios de nombres de usuario para usuarios sin privilegios. Bubblewrap necesita un espacio de nombres de usuario para crear su sandbox, por lo que bwrap no puede iniciarse. Como la aplicación no convierte archivos sin un sandbox, todos los trabajos fallan.

Compruébelo directamente:

bwrap --ro-bind / / --dev /dev /bin/true && echo sandbox ok

Un error de permiso denegado indica que el espacio de nombres está bloqueado. La solución consiste en crear un perfil de AppArmor para el binario bwrap. Primero, enumere los archivos ABI y anote el número más alto disponible:

ls /etc/apparmor.d/abi/

A continuación, escriba /etc/apparmor.d/bwrap y sustituya 4.0 por ese número:

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}

Cárguelo:

sudo apparmor_parser -r /etc/apparmor.d/bwrap

Si no se muestra ninguna salida, el perfil se ha cargado. Vuelva a ejecutar la comprobación bwrap. Debería mostrar sandbox ok. A partir de ese momento, las conversiones funcionan.

Un conversor público es un analizador expuesto a desconocidos

Esta es la sección para la que existe el resto del artículo. Un conversor de archivos accesible desde Internet acepta un archivo arbitrario de una persona anónima y se lo entrega a LibreOffice, ImageMagick, FFmpeg o Ghostscript. Son bases de código grandes escritas en C y C++, con un historial extenso de errores en analizadores. La persona que carga el archivo elige el formato. Por tanto, también elige qué analizador se ejecuta y qué ruta de código interna se utiliza.

La respuesta de HRConvert2 consiste en ejecutar cada dependencia dentro de un espacio de nombres de bubblewrap. Cada conversión ve dos directorios: el que contiene la entrada, montado como de solo lectura, y el que recibe la salida. La red no se comparte. En palabras del proyecto, closes every URL handler in every dependency at once. Esto es más importante de lo que parece. ImageMagick y Ghostscript aceptan referencias que recuperan una URL. Así, un conversor puede convertirse en una herramienta de falsificación de peticiones del lado del servidor (SSRF) para acceder a un endpoint de metadatos de la nube desde la red interna. Sin red en el espacio de nombres, la recuperación no puede realizarse.

El rechazo es la otra mitad: A server that cannot build a sandbox refuses the conversion rather than quietly running without one. Una herramienta que falla de forma segura vale más que una que muestra una advertencia en un registro que nadie lee. Por eso el paso de AppArmor anterior no es opcional. También por eso conviene revisar $RequireSandboxOnDocker antes de exponer el contenedor.

Fortalecer ImageMagick con policy.xml

El archivo de políticas de ImageMagick añade una segunda capa bajo el sandbox y conviene configurarlo. En Ubuntu 24.04 con ImageMagick 6, el archivo es /etc/ImageMagick-6/policy.xml. Muestre la configuración activa:

identify -list policy

El proyecto incluye una política en Documentation/Build/policy.xml que sirve como buen modelo. Deniega los coders PS, PS2, PS3, EPS, XPS y MVG, y deniega los delegates URL, HTTPS, HTTP y gs, mientras permite PDF:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="delegate" rights="none" pattern="URL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="read|write" pattern="PDF" />

La línea gs es la importante. ImageMagick no analiza PostScript directamente. Ejecuta Ghostscript mediante un proceso externo, y en ese delegate se encuentran las conocidas vulnerabilidades de ejecución remota de código de ImageMagick. Si deniega el delegate, ImageMagick no entregará nunca un archivo subido a gs, independientemente del tipo que declare el archivo.

La misma política establece límites de recursos. Así se evita que una sola imagen especialmente preparada consuma toda la máquina:

<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="width" value="16KP"/>
<policy domain="resource" name="height" value="16KP"/>
<policy domain="resource" name="area" value="128MP"/>

Un descompresor-bomba es un archivo pequeño que declara dimensiones enormes. Los límites width, height y area lo rechazan antes de asignar memoria, por lo que el proceso termina en lugar de que el kernel mate otro proceso.

También existe un problema en la otra dirección. La política predeterminada de Ubuntu deniega por completo el coder PDF. Por eso, en un sistema sin modificar, el procesamiento de PDF falla con attempt to perform an operation not allowed by the security policy 'PDF'. Esa cadena indica que la política está funcionando. Volver a permitir el coder es una decisión deliberada, y al hacerlo debe mantener denegado el delegate gs.

Coste de la cadena de dependencias en un VPS pequeño

En reposo, nada de esto consume mucho. Apache y PHP ocupan unas pocas decenas de megabytes y los binarios de conversión no están ejecutándose. Todo el consumo aparece de golpe cuando llega un archivo.

Una conversión de documentos inicia LibreOffice, que a su vez inicia un entorno de ejecución de Java. Una conversión de imágenes asigna a ImageMagick 256 MiB de memoria y un mapa de memoria de 512 MiB según la política anterior. Una conversión de vídeo da a FFmpeg todos los núcleos disponibles, porque así procesa FFmpeg el vídeo. El propio memory_limit de PHP está configurado en 512M en el proyecto. Estos valores se acumulan durante una sola tarea, además del sistema operativo y el servidor web.

Por eso, un VPS de 1 GB empieza a usar swap con el primer documento real y después entra en una situación de thrashing. Cuando se agota la memoria, el kernel out of memory killer termina el proceso con el mayor tamaño residente. Normalmente es soffice.bin, y el usuario ve una conversión fallida sin ningún mensaje útil. A veces es apache2, y todo el sitio deja de funcionar. Confírmelo después con dmesg -T | grep -i "killed process".

Esto es una recomendación de dimensionamiento, no una prueba de rendimiento: 4 GB de RAM y dos núcleos ofrecen margen suficiente para un equipo pequeño, y 2 GB con un archivo de swap funcionan si la carga consiste en documentos e imágenes y acepta la espera. Un archivo de swap no acelera una conversión. Hace que un pico de carga sea lento en lugar de fatal. Esa es la diferencia entre una página bloqueada y una interrupción del servicio. Reserve más espacio en disco del que parezca necesario, porque la imagen de 3 GB, un límite de carga elevado y el resultado convertido pueden llenar el disco mucho antes de que se agote cualquier otro recurso.

Las conversiones generan picos de carga por naturaleza. Dos personas que carguen vídeo al mismo tiempo utilizarán todos los núcleos, y la siguiente petición tendrá que esperar. No hay una cola de tareas delante de este proceso, por lo que el único control disponible son los límites.

Establezca límites para evitar que una sola carga llene el disco

Reduzca primero los valores de PHP. upload_max_filesize = 512M, post_max_size = 512M y max_file_uploads = 20 son un punto de partida razonable para un servidor compartido de 4 GB. Tenga en cuenta que max_execution_time = 1200 permite que una petición de PHP se ejecute durante veinte minutos. Ese tiempo puede ser necesario para convertir un vídeo largo, pero también significa que una carga lenta mantiene ocupado un worker durante veinte minutos.

Aplique después el límite de tamaño y de tiempo en el proxy, antes de que la petición llegue a PHP:

limit_req_zone $binary_remote_addr zone=convert:10m rate=6r/m;

server {
    listen 443 ssl;
    server_name convert.example.com;

    client_max_body_size 512M;
    client_body_timeout 300s;

    location / {
        limit_req zone=convert burst=4 nodelay;
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 1200s;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

client_max_body_size debe ser como mínimo igual al tamaño del archivo más grande que quiera convertir. De lo contrario, nginx responde con 413 Request Entity Too Large y PHP nunca recibe la carga. proxy_read_timeout debe ser superior a la duración de la conversión más larga. De lo contrario, un trabajo que se ejecuta correctamente detrás del proxy devuelve 504 Gateway Time-out al navegador. El resto de ese bloque de servidor, incluida la terminación de TLS (transport layer security), se explica en una configuración de reverse proxy de nginx explicada línea por línea.

Eliminar los archivos convertidos

Cada conversión deja una copia de un archivo sensible en un directorio que el servidor web puede leer. La limpieza es lo que diferencia un conversor de un archivo con todo lo que alguien haya convertido alguna vez en él.

$DeleteThreshold en Resources/config.php indica la antigüedad, en minutos, a partir de la cual caduca una sesión, y el valor predeterminado es 60. Redúzcalo a 15 cuando el contenido sea sensible. La limpieza se ejecuta mediante un argumento de línea de comandos del núcleo:

sudo -u www-data php /path/to/HRConvert2/convertCore.php -c
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c=15

-c elimina las sesiones caducadas de las dos ubicaciones de datos mediante el umbral configurado. -c=15 usa quince minutos sólo para esa ejecución. -c=now elimina todas las sesiones, independientemente de su antigüedad, incluida la sesión que un usuario esté usando para convertir un archivo en ese momento, por lo que debe reservarse para tareas de mantenimiento. Los mismos argumentos funcionan dentro del contenedor mediante docker exec.

Programe la limpieza con un temporizador para que nunca dependa de que alguien cargue una página. Basta con añadir una línea en /etc/cron.d/hrconvert2:

*/10 * * * * www-data php /path/to/HRConvert2/convertCore.php -c

Compruébelo unos minutos después con ls /DATA/HRConvert2 y observe cómo desaparecen los directorios de sesión antiguos. Como el usuario del servidor web es el propietario de ese directorio, esa cuenta es exactamente lo que obtendría un analizador comprometido. Por tanto, no debería ser propietaria de ningún otro recurso valioso. Cuentas de usuario con privilegios mínimos en un VPS es el patrón general y aquí se aplica más que de costumbre.

Colóquelo detrás de autenticación, salvo que el objetivo sea que sea público

La instalación predeterminada no tiene cuentas, por diseño. Cualquiera que pueda acceder a la página puede cargar un archivo y ejecutar los binarios de conversión, y los límites de tasa sólo ralentizan el proceso. Por tanto, determine en qué situación se encuentra.

Si es para usted y algunos colegas, no lo exponga en absoluto. Vincule el contenedor a loopback como se muestra arriba y acceda a él mediante una red privada o un túnel SSH. Así, nada en Internet público podrá enviarle archivos, lo que elimina toda la superficie de ataque en lugar de limitarla mediante filtros.

Si debe ser accesible desde un navegador, coloque la autenticación delante del proxy. Basic auth requiere dos comandos y mantiene el formulario de carga alejado de personas no autorizadas:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice

location / {
    auth_basic "Converter";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:8080;
}

Recargue nginx y cargue la página. Si aparece un aviso, funciona correctamente. Si no aparece, el bloque location que editó no es el que gestiona la solicitud. Para usar cuentas reales en lugar de una contraseña compartida, termine la autenticación en un proveedor de inicio de sesión único: un servidor SSO Authentik autohospedado proporciona autenticación delegada delante de una aplicación que no tiene su propio inicio de sesión.

Si el objetivo es ofrecer un convertidor realmente público, acepte las implicaciones y planifíquelo. Suponga que se probará el sandbox. Mantenga fijada la etiqueta de la imagen, mantenga estricta la política de ImageMagick, mantenga bajos los límites de carga y ejecútelo en un VPS que no aloje nada más importante.

Modos de fallo y mensajes que verá

Todas las conversiones fallan inmediatamente. No se puede crear el sandbox. En una instalación normal, la causa es el perfil de AppArmor. En Docker, falta --security-opt seccomp=unconfined. La aplicación lo indica: A sandbox blocks the required syscalls unless it was started with the correct options. y señala See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php.

Sólo fallan las conversiones de imágenes. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! significa que bwrap no existe o no está disponible en las rutas que puede usar el usuario del servidor web.

Falla un formato y los demás funcionan. Falta un binario. El mensaje lo indica claramente: ImageMagick may not be installed, or may not be reachable on the system path used by the web server user.. El mismo mensaje existe para FFmpeg y LibreOffice. Ejecute convertCore.php -v para ver qué encuentra la instalación. Recuerde que el PATH del proceso de Apache no es el mismo que el PATH de su shell de inicio de sesión.

Las operaciones con PDF fallan con un error de política. attempt to perform an operation not allowed by the security policy 'PDF' procede de policy.xml de ImageMagick, no de HRConvert2.

Las cargas grandes devuelven 413. client_max_body_size de nginx es menor que el tamaño del archivo. Hay tres límites en la cadena: uno en nginx y dos en PHP. Se aplica el menor.

Las conversiones se detienen y no hay cambios evidentes. The device where data is stored has an insufficient amount of storage space available.. Compruebe el espacio libre y confirme que la tarea de limpieza se está ejecutando.

La limpieza genera errores en el registro. Could not clean the temporary location! y Could not clean the convert location! son problemas de propiedad. El usuario del servidor web debe ser propietario del directorio indicado por $ConvertLoc.

FAQ

¿Es seguro exponer un conversor de archivos autohospedado a Internet?

Sólo es suficientemente seguro si lo trata como un analizador expuesto a usuarios desconocidos. Cada archivo subido se entrega a LibreOffice, ImageMagick, FFmpeg o Ghostscript, y la persona que lo sube determina cuál se utiliza. HRConvert2 ejecuta esas herramientas dentro de un espacio de nombres de bubblewrap sin red y con un directorio de entrada de sólo lectura. Además, rechaza cualquier conversión que no pueda ejecutar dentro del sandbox, lo que proporciona una configuración predeterminada sólida. Aun así, es preferible exigir autenticación, mantener bajos los límites de subida y ejecutarlo en un VPS que no contenga ningún otro recurso importante.

¿Por qué fallan todas las conversiones en una instalación nueva de Ubuntu 24.04?

Ubuntu 24.04 y Debian 12 restringen los espacios de nombres de usuario sin privilegios, y bubblewrap necesita uno para crear su sandbox. Como la aplicación rechaza las conversiones sin sandbox, fallan todos los trabajos en lugar de fallar sólo algunos. Escriba un perfil de AppArmor para /usr/bin/bwrap con flags=(unconfined), cárguelo con sudo apparmor_parser -r /etc/apparmor.d/bwrap y confírmelo con bwrap --ro-bind / / --dev /dev /bin/true.

¿Por qué fallan las conversiones en Docker, pero funcionan en una instalación normal?

El perfil seccomp predeterminado de Docker bloquea las llamadas al sistema que utiliza bubblewrap, por lo que el sandbox no puede crearse dentro del contenedor. Inícielo con --security-opt seccomp=unconfined, que es lo que utiliza el propio comando de ejecución del proyecto. Tenga en cuenta que $RequireSandboxOnDocker es FALSE de forma predeterminada, por lo que un contenedor sin esa opción puede convertir archivos sin ningún sandbox. Establézcalo en TRUE después de activar la opción de seccomp.

¿Cuánta RAM necesita un servidor de conversión de archivos?

El consumo en reposo es bajo, pero una conversión activa requiere más recursos. LibreOffice inicia un runtime de Java, ImageMagick utiliza 256 MiB de memoria y un mapa de 512 MiB según la política incluida, y el límite propio de PHP es 512M. En un VPS de 1 GB, esa combinación provoca intercambio y el killer de memoria insuficiente termina soffice.bin o apache2. Planifique 4 GB y dos núcleos para un equipo pequeño, y revise dmesg -T | grep -i "killed process" cuando una conversión termine sin mostrar ningún mensaje.

¿Dónde se guardan los archivos convertidos y cuándo se eliminan?

Se guardan en el directorio de trabajo indicado por $ConvertLoc en Resources/config.php, cuyo valor predeterminado es /DATA/HRConvert2. $DeleteThreshold establece en minutos la antigüedad a partir de la cual caduca una sesión, y su valor predeterminado es 60. La limpieza se ejecuta desde la línea de comandos: php convertCore.php -c elimina las sesiones caducadas y -c=now elimina inmediatamente todas las sesiones, incluidas las activas. Añada -c a una entrada de cron o a un temporizador de systemd para que la eliminación no dependa de que alguien visite el sitio.