Implementación y actualizaciones

Para su primera configuración local, siga Primera solicitud. Utilice esta página al elegir un método de implementación, configurar una instancia remota o actualizar.

SubLane se ejecuta como un proceso con una interfaz integrada y SQLite. La producción no requiere Node.js, Redis ni un servicio de proxy independiente. Ejecute una instancia en cada directorio de datos.

Imágenes publicadas Docker

Publicación de lanzamientos etiquetados ghcr.io/murongg/sublane para linux/amd64 y linux/arm64. Docker selecciona la arquitectura del host. Las imágenes son públicas y se pueden extraer sin iniciar sesión en GHCR. La implementación requiere Docker con Compose; no se necesita extracción de código fuente, Go, Node.js o creación de imágenes locales.

Los ejemplos del manual Compose a continuación fijan el publicado 0.1.0-rc.1 prelanzamiento. Colocar SUBLANE_IMAGE explícitamente para implementaciones manuales: el valor predeterminado Compose es latest, que sólo se publica con una versión estable.

Utilice una versión fija o un resumen para implementaciones repetibles. Una nueva imagen que aparece en GHCR no actualiza automáticamente un contenedor en ejecución.

Instalar script

Ejecute el instalador desde una terminal para elegir Docker o un binario de Linux publicado, una instancia normal o una demostración de solo lectura, luego sin proxy, Caddy o Nginx:

Utilice Arriba/Abajo o una tecla numérica para resaltar una opción, luego Ingresar para confirmar. La primera opción está seleccionada de forma predeterminada. Los terminales básicos utilizan mensajes de texto numerados. El dominio sigue siendo una entrada de texto y el instalador muestra la configuración generada para su confirmación antes de la implementación. Las banderas suministradas omiten sus opciones correspondientes; --non-interactive desactiva todas las indicaciones.

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash

Sin --version, el script selecciona la última versión estable de GitHub. Sólo cuando no existe una versión estable selecciona la versión preliminar publicada más recientemente, excluyendo los borradores. La versión concreta seleccionada se guarda en la configuración generada, por lo que los reinicios no cambian las versiones silenciosamente. GitHub API Los errores detienen la instalación en lugar de activar un retroceso del canal.

El script verifica el artefacto de versión seleccionado contra SHA256SUMS antes de instalarlo en un nuevo ./sublane directorio. Bash, curl y cualquiera de los dos sha256sum o shasum son requeridos; La selección automática de versión requiere además jq. El modo Docker requiere Docker Compose y espera a que el contenedor esté en buen estado. El modo binario admite Linux amd64/arm64, requiere un administrador de usuarios systemd que funcione, habilita un servicio de usuario y espera /readyz. No instala Docker, Caddy o Nginx, y no compila desde el código fuente.

Para elegir una versión publicada, un nuevo directorio y un puerto de host sin indicaciones:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --version 0.1.0-rc.1 --dir ./team-gateway --port 8088 --runtime docker --proxy none --non-interactive

Las etiquetas de versión pueden incluir el encabezado v. El puerto backend permanece vinculado a 127.0.0.1. Cuando no hay terminal disponible, una instancia normal que usa Docker sin proxy sigue siendo la opción predeterminada; aprobar --runtime, --proxy, o --demo para seleccionar otros modos. Para un servidor remoto, utilice un túnel SSH para la configuración inicial o configure el HTTPS proxy inverso.

El instalador utiliza ss (de iproute2) o lsof para verificar el puerto de backend seleccionado antes de descargar y nuevamente antes de crear la implementación. Si un detector de bucle invertido o comodín ya utiliza ese puerto, se detiene y le pide que elija un puerto no utilizado con --port, Por ejemplo --port 8088. Instale cualquiera de las utilidades si ninguna está disponible. Un proxy existente en los puertos 80 o 443 no bloquea una instalación que utiliza el puerto backend 8080. Las comprobaciones no pueden reservar el puerto; Las comprobaciones de estado de inicio aún detectan los conflictos que aparecen después.

Por ejemplo, elija el binario publicado y genere un Caddyfile para un dominio público:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --runtime binary --proxy caddy --domain sublane.example.com

--domain Es opcional con Caddy o Nginx. Sin él, el proxy generado escucha 127.0.0.1:80 más de HTTP y SUBLANE_PUBLIC_URL permanece desarmado. Con un dominio, el instalador establece SUBLANE_PUBLIC_URL=https://<domain> y genera una configuración de proxy HTTPS. Muestra la configuración antes de instalar, pero no lo copia ni recarga el servicio proxy. Revisar lo generado Caddyfile o nginx.conf y aplícalo tú mismo; la plantilla de Nginx asume archivos de certificado en /etc/letsencrypt/live/<domain>/.

Para Docker, el instalador escribe la imagen seleccionada, el puerto y un nombre de proyecto único Compose en .env. Guárdalo con docker.compose.yaml; identifica el volumen de datos de la implementación. Para el modo binario, genera sublane.env, start.sh y una unidad de usuario systemd vinculada; los datos permanecen en un privado data/ directorio. Un servicio de usuario de systemd puede detenerse cuando el usuario cierra la sesión, a menos que esté habilitado el modo persistente; controlar loginctl show-user "$USER" -p Linger y organice la permanencia si necesita una operación desatendida. Las nuevas instalaciones rechazan directorios y enlaces simbólicos existentes. Una instalación existente administrada por script se puede actualizar con el mismo script, como se describe a continuación. Si el inicio falla, la configuración y los datos creados se conservan para su inspección.

Actualizar una instalación administrada por script

Primero exportar y verificar una copia de seguridad de la base de datosy lea las notas de la versión de destino. Ejecute el script desde el directorio principal del directorio de instalación. En una terminal, un objetivo existente ofrece Actualizar instancia existente y solicita confirmación antes del despliegue. Para seleccionar la actualización explícitamente:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --update --dir ./sublane

Sin --version, las actualizaciones utilizan la misma selección estable/prelanzamiento que la instalación. Agregar --version <published-version> para fijar un lanzamiento, --wait-timeout 120 para cambiar la espera de preparación, o --non-interactive para omitir la confirmación. El script detecta el tiempo de ejecución existente; banderas de solo instalación como --runtime, --port, --proxy y --demo son rechazados durante las actualizaciones.

Las actualizaciones Docker conservan el archivo Compose y el nombre del proyecto, solo cambian SUBLANE_IMAGE en .env, extraiga la imagen seleccionada y vuelva a crear el servicio con una espera de estado. Las actualizaciones binarias verifican el archivo, reemplazan los archivos de documentación/licencia ejecutables y empaquetados, reinician la unidad de usuario systemd existente y esperan /readyz. Se conservan los archivos de entorno, el iniciador, la unidad de usuario, la configuración del proxy y las rutas de datos. Se espera que el puerto existente del servicio esté ocupado, por lo que las actualizaciones no ejecutan comprobaciones de puertos de nueva instalación.

Los errores de descarga, suma de comprobación, configuración y extracción de imágenes dejan los archivos implementados sin cambios. Antes del reemplazo, el script guarda los archivos de configuración/programa anteriores en un archivo privado. .update-backup.* directorio dentro de la instalación e imprime su ruta. Estos archivos no son una copia de seguridad de la base de datos. El inicio fallido los conserva junto con los datos de implementación actuales para inspección, informa fallas y no ejecuta automáticamente una versión anterior en una base de datos potencialmente migrada. Seguir recuperación y reversión cuando es necesaria la restauración de datos. Se rechaza una actualización simultánea; si el proceso fue eliminado por la fuerza, eliminar .update-lock Sólo después de confirmar no queda ninguna actualización activa.

Esta ruta de actualización admite instalaciones creadas por el script. Las implementaciones manuales y las implementaciones que requieren archivos de anulación Compose adicionales deben usar el procedimiento de actualización manual, incluidas todas las anulaciones en inicios posteriores.

Para revisar el script antes de ejecutarlo, descárguelo con curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh -o install.sh, luego corre bash install.sh --help o bash install.sh después de revisarlo.

Implementación manual Compose

Cree un directorio de implementación y descargue docker.compose.yaml de los seleccionados GitHub Liberar:

mkdir sublane && cd sublane
curl -fsSL https://github.com/murongg/SubLane/releases/download/v0.1.0-rc.1/docker.compose.yaml -o docker.compose.yaml

En ese directorio, cree un Compose .env archivo para mantener la versión de la imagen seleccionada durante reinicios y actualizaciones:

SUBLANE_IMAGE=ghcr.io/murongg/sublane:0.1.0-rc.1
SUBLANE_BIND_ADDRESS=127.0.0.1
SUBLANE_PORT=8080
SUBLANE_LOG_LEVEL=info
# Add this when using an HTTPS reverse proxy:
# SUBLANE_PUBLIC_URL=https://sublane.example.com
# In Docker, first identify the proxy source IP as seen inside the container:
# SUBLANE_TRUSTED_PROXIES=<proxy-source-ip>/32

Compose lee .env para interpolación; la aplicación Go independiente no se carga .env sí mismo. Un resumen inmutable se puede utilizar como el conjunto completo. SUBLANE_IMAGE valor en lugar de una etiqueta.

docker compose -f docker.compose.yaml pull
docker compose -f docker.compose.yaml up -d
docker compose -f docker.compose.yaml ps
docker compose -f docker.compose.yaml logs --tail=100 sublane

Abierto http://127.0.0.1:8080 y complete la configuración del administrador antes de permitir el acceso a los miembros. Para un host remoto, utilice un túnel SSH para la configuración inicial. La asignación predeterminada Compose permanece en bucle invertido; publicación 0.0.0.0 es una elección explícita del operador.

La imagen se ejecuta como el Alpine existente. sublane cuenta de servicio, incluye certificados de CA, avisos de licencia y cheques /readyz. Compose utiliza un sistema de archivos raíz de solo lectura, con capacidad de escritura de 64 MiB /tmp tmpfs para SDK archivos borrador, capacidades de Linux eliminadas, registros de contenedores limitados y un período de gracia de parada de 30 segundos. El contenedor escucha en el puerto 8080; personalizar el puerto del host a través de SUBLANE_PORT. Si anula el puerto de escucha interno usted mismo, cambie también la verificación de estado y la asignación de puertos.

Datos persistentes

el nombrado sublane-data retenciones de volumen /data/sublane.db, sus archivos WAL y /data/credentials.key. Guarde la clave de cifrado con la base de datos. Las claves de servicio/volumen Compose existentes se conservan, por lo que las actualizaciones de compilaciones fuente anteriores siguen usando el mismo volumen cuando se ejecutan desde el mismo proyecto Compose.

Mantenga coherente el nombre/directorio del proyecto Compose. Cambiarlo crea un volumen con nombre diferente y puede hacer que una instancia existente parezca no inicializada. no corras docker compose -f docker.compose.yaml down -v al actualizar o recuperar: eso elimina el volumen de datos. Se admiten montajes vinculados, pero sus permisos de host deben permitir que la cuenta no raíz de la imagen escriba el directorio montado. Prefiere el volumen con nombre predeterminado a menos que la propiedad de la ruta del host sea intencional.

Construir desde la fuente

Para compilar localmente, clone el repositorio y use la anulación de compilación de código fuente:

git clone https://github.com/murongg/SubLane.git
cd SubLane
docker compose -f docker.compose.yaml -f docker.compose.build.yaml up --build -d

Utilice ambos archivos para comandos posteriores en esa implementación. Para configurar metadatos de compilación:

VERSION=0.1.0-dev REVISION=$(git rev-parse HEAD) \
  docker compose -f docker.compose.yaml -f docker.compose.build.yaml build

El Dockerfile compila Go for TARGETOS/TARGETARCH desde las etapas de compilación nativas, por lo que la compilación de ARM64 en x86-64 no emula el compilador ni la compilación del frontend. Se puede crear una imagen multiplataforma con un generador Buildx configurado:

docker buildx build --platform linux/amd64,linux/arm64 \
  --build-arg VERSION=0.1.0-dev --output type=oci,dest=dist/sublane.oci.tar .

Crear dist primero. Una compilación/carga local normal normalmente tiene como objetivo una plataforma. Ver Docker guía de compilación cruzada.

Binario de Linux independiente

Descargue el archivo que coincida con su máquina y SHA256SUMS del mismo lanzamiento:

• sublane_VERSION_linux_amd64.tar.gz: x86-64.
• sublane_VERSION_linux_arm64.tar.gz: AArch64.

En Linux, verifique los archivos descargados, extraiga el archivo en un directorio con nueva versión y ejecute:

sha256sum --check --ignore-missing SHA256SUMS
./sublane --version
SUBLANE_ADDR=127.0.0.1:8080 SUBLANE_DATA_DIR=/srv/sublane/data ./sublane

El archivo contiene el ejecutable, los textos de licencia AGPL y de terceros, el archivo Compose, un ejemplo de entorno y documentación de implementación/copia de seguridad. Mantenga el directorio de datos fuera del directorio ejecutable versionado, hágalo privado y el usuario del servicio pueda escribirlo y utilice un supervisor de procesos para una operación persistente. El instalador guiado puede realizar esta configuración con un servicio de usuario de systemd. No ejecute la puerta de enlace como root.

Modo de demostración

El instalador ofrece instancia normal o demostración de solo lectura después de la elección del tiempo de ejecución. El modo normal sigue siendo el predeterminado. Para seleccionar el modo de demostración directamente:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- --demo

--demo funciona con ambos --runtime docker y --runtime binary. Agregar --non-interactive para utilizar los valores predeterminados para las opciones restantes. El instalador escribe SUBLANE_DEMO=true a .env para Compose o sublane.env para el servicio binario y muestra el inicio de sesión de demostración pública después de la instalación. Un heredado SUBLANE_DEMO no anula el modo seleccionado por el instalador.

El soporte de demostración debe estar presente en la configuración verificada de la versión seleccionada. El instalador rechaza versiones anteriores antes de extraer/iniciar contenedores o habilitar un servicio; usar --version para seleccionar una versión que incluya soporte de demostración. No vuelve a una instancia normal.

En una compilación que contenga soporte de demostración, inicie una demostración de solo lectura con:

SUBLANE_DEMO=true ./sublane

Abra la dirección del servidor habitual y elija Explorar demostracióno inicia sesión con tu nombre de usuario demo y contraseña sublane-demo. La aplicación muestra cuentas de suscripción de muestra, grupos, miembros, API metadatos clave, historial de solicitudes y 30 días de uso claramente etiquetados. Las preferencias de navegación, filtros, idioma y tema funcionan normalmente. Los formularios se pueden inspeccionar, pero las escrituras, la divulgación de credenciales, OAuth, las copias de seguridad y todas las llamadas de puerta de enlace (incluidas WebSocket) están bloqueadas; El inicio de sesión y el cierre de sesión permanecen disponibles.

Cada inicio crea una nueva base de datos temporal privada y una clave de cifrado. El modo de demostración no se abre SUBLANE_DATA_DIR, cachés de precios o credenciales reales, y no se pone en contacto con proveedores ni servicios de lanzamiento/precios. El cierre elegante elimina los archivos temporales; una muerte abrupta puede dejar un sublane-demo-* directorio en el directorio temporal del sistema operativo. Al reiniciar se recrean los ejemplos con fechas recientes. Detener la demostración y desarmar SUBLANE_DEMO para reanudar una instalación normal.

Para el desarrollo, utilice SUBLANE_DEMO=true make dev. Con el archivo Compose de esta versión, configure SUBLANE_DEMO=true en .env y recrear el contenedor. Las versiones publicadas existentes sin soporte de demostración deben actualizarse o reconstruirse primero. Se siguen aplicando las configuraciones habituales de dirección de escucha, origen externo y proxy confiable.

Configuración de tiempo de ejecución

El servicio independiente lee estas variables de entorno de proceso; .env.example enumera ejemplos. No carga un .env archivo automáticamente. Compose lee .env para su propia interpolación y pasa el entorno configurado al contenedor.

La imagen Docker anula la dirección de escucha para 0.0.0.0:8080 y directorio de datos para /data. SUBLANE_IMAGE, SUBLANE_BIND_ADDRESS y SUBLANE_PORT configure Compose únicamente. SQLite inicializa el esquema consolidado en una base de datos nueva y utiliza una única conexión de base de datos.

El inicio inicializa bases nuevas y aplica las migraciones pendientes, en orden, a las bases existentes compatibles. Rechaza la estructura preliminar incompatible con 001_settings.sql; conserva su directorio antes de comenzar con uno nuevo. Exporta y verifica una copia de seguridad antes de actualizar. Cambiar solo la imagen no revierte los datos migrados.

SUBLANE_MAX_REQUEST_BODY_MB se aplica a solicitudes de puerta de enlace HTTP, mensajes WebSocket y contexto de conversación reconstruido. Responses y los eventos de transmisión conservan sus límites separados de 8 MiB. Reinicie el servicio independiente o vuelva a crear el contenedor después de cambiar el límite de solicitudes y alinee los límites del cuerpo del proxy inverso con el nuevo valor.

Si anulas SUBLANE_PRICING_URL, también establece SUBLANE_PRICING_HASH_URL al archivo SHA-256 correspondiente para mantener habilitadas las comprobaciones de integridad del documento. Una URL de precio personalizada sin una URL hash se recupera y analiza, pero no se verifica mediante hash.

Los cambios en el tiempo de ejecución de la puerta de enlace requieren un reinicio o una recreación del contenedor. El archivo Compose actual pasa estas variables. Las actualizaciones administradas por script conservan los archivos Compose existentes; agregue las nuevas entradas del entorno a un archivo Compose guardado más antiguo antes de confiar en .env anula. La configuración de simultaneidad de cuenta/miembro permanece por separado.

HTTPS proxy inverso

Colocar SUBLANE_PUBLIC_URL al origen externo exacto, como https://sublane.example.comy vuelva a crear el servicio para que los cambios del entorno surtan efecto. Esto es necesario detrás de un proxy inverso porque el respaldo deriva el origen del encabezado Host de la solicitud. El origen configurado se utiliza para comprobaciones de solicitudes del navegador y cookies de sesión segura. Reenvíe el encabezado del host original y conserve la transmisión y las actualizaciones WebSocket.

Colocar SUBLANE_TRUSTED_PROXIES a las direcciones CIDR de sus propios saltos de proxy. Para un binario independiente SubLane alcanzado a través de loopback IPv4, use 127.0.0.1/32 (agregar ::1/128 para bucle invertido IPv6). Un contenedor Docker puede ver el proxy del host como su dirección de puente en lugar de bucle invertido; el instalador deja este valor vacío en el modo Docker a menos que pase --trusted-proxies con la dirección SubLane realmente ve. Para un contenedor proxy, utilice su dirección fija o una subred privada dedicada y de alcance limitado. SubLane ignora X-Forwarded-For a menos que el par directo coincida con esta lista, entonces utiliza la IP no confiable más a la derecha en la cadena para los límites de inicio de sesión. Mantenga el acceso directo a SubLane restringido al proxy cuando esté configurado. Sin él, todos los usuarios detrás de un proxy comparten el límite de inicio de sesión del proxy.

Para un proxy Caddy ejecutándose en el mismo host:

sublane.example.com {
    reverse_proxy 127.0.0.1:8080
}

Caddy maneja las actualizaciones TLS y WebSocket y vacía las respuestas SSE automáticamente. Mantenga el comportamiento de descarga predeterminado para que las desconexiones de clientes puedan cancelar el trabajo ascendente; negativo flush_interval cambia ese comportamiento de cancelación. Ver el Referencia de proxy inverso de Caddy. Si el proxy es otro contenedor, use el nombre del servicio Compose sublane:8080 en una red compartida; 127.0.0.1 dentro del contenedor proxy se refiere a ese contenedor en sí.

Para una instalación de Nginx existente, coloque el mapa en el http contexto y use estas ubicaciones dentro de su bloque de servidor HTTPS:

map $http_upgrade $sublane_connection {
    default upgrade;
    ''      close;
}

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $sublane_connection;
    proxy_buffering off;
    proxy_read_timeout 650s;
    proxy_send_timeout 650s;
    client_max_body_size 128m;
}

# Web backup uploads/downloads can be larger and last up to 15 minutes.
location /api/settings/backup/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_request_buffering off;
    proxy_buffering off;
    proxy_read_timeout 950s;
    proxy_send_timeout 950s;
    client_max_body_size 256m;
}

Configure el certificado HTTPS en el servidor Nginx principal. El Guía de Nginx WebSocket explica los encabezados de actualización explícitos. Los límites también deben permitir los tamaños de solicitud/copia de seguridad en cualquier otra capa de proxy. Siguen vigentes la autorización propia de la pasarela y los límites corporales.

Mejora

1. Revise las notas de la versión y registre la versión/resumen de la imagen actual.

2. Exporte una copia de seguridad consistente y cópiela del volumen de datos:

   docker compose -f docker.compose.yaml exec sublane sh -c 'mkdir -p /data/backups'
   docker compose -f docker.compose.yaml exec sublane sublane backup --output /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml exec sublane sublane backup verify --input /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml cp sublane:/data/backups/pre-upgrade.sublane-backup.tar.gz ./pre-upgrade.sublane-backup.tar.gz
   chmod 600 ./pre-upgrade.sublane-backup.tar.gz

   Utilice un nuevo nombre de archivo para cada actualización; Las copias de seguridad existentes nunca se sobrescriben. El archivo incluye la clave de cifrado y pertenece a un almacenamiento privado.

3. Cambiar SUBLANE_IMAGE en .env a la versión seleccionada, luego extraiga y vuelva a crear:

   docker compose -f docker.compose.yaml pull
   docker compose -f docker.compose.yaml up -d
   docker compose -f docker.compose.yaml ps
   docker compose -f docker.compose.yaml logs --tail=100 sublane

4. Confirme el estado, el inicio de sesión, las cuentas/grupos/claves esperados y una llamada de cliente explícitamente autorizada. Una base de datos nueva recibe el esquema SQLite consolidado al inicio. El estado de la imagen verifica la preparación del proceso/base de datos, no la autorización real del proveedor.

Recuperación y reversión

Cambiar una etiqueta de imagen por sí solo no es una reversión de la base de datos. Si una versión migró el esquema, restaure el archivo previo a la actualización en un nuevo directorio con la imagen/binario anterior deseado, luego detenga el servicio actual y cambie a ese directorio restaurado. Conserve el volumen original hasta que se complete la verificación. Nunca permita que dos procesos compartan el mismo directorio SQLite.

El guía de respaldo cubre la preparación de restauración web y CLI y la anulación Compose para /data/restore-ready. Continúe usando la anulación de restauración en inicios posteriores mientras ese directorio esté activo. Una copia de seguridad de un esquema más nuevo no se puede abrir con una versión anterior que no la reconozca.

Verificación de contenedores

Con el motor Docker en marcha:

docker compose -f docker.compose.yaml config --quiet
docker compose -f docker.compose.yaml -f docker.compose.build.yaml config --quiet
docker buildx build --load --build-arg VERSION=0.0.0-test -t sublane:smoke .
bash scripts/container-smoke.sh sublane:smoke 0.0.0-test

El script de humo crea su propio volumen y contenedor desechables con nombre, con la conexión en red deshabilitada. Comprueba el estado, la versión, la ejecución no root, las rutas de ejecución de solo lectura, la configuración de primera ejecución con credenciales sintéticas, los permisos clave, la copia de seguridad/verificación/restauración y la persistencia después del reinicio. Elimina solo esos recursos temporales. No se pone en contacto con proveedores ascendentes ni utiliza datos de instancias existentes. CI ejecuta las mismas comprobaciones en los corredores nativos amd64 y arm64.