Instalación

EQProxy se distribuye como binario estático para Linux y macOS y como imagen multiarquitectura en dos registros. Esta página cubre las dos vías, los requisitos reales del binario y el primer arranque con un TOML mínimo, incluida la validación previa por CLI.

Binario y compilación

Cada release publica cuatro binarios precompilados — eqproxy-darwin-arm64, eqproxy-darwin-amd64, eqproxy-linux-arm64 y eqproxy-linux-amd64 —, el código fuente como eqproxy-0.9.1-src.tar.gz y un único SHA256SUMS.txt que cubre los cinco artefactos.

Los binarios de Linux están enlazados estáticamente contra musl (static-pie linked en amd64, statically linked en arm64): no necesitan libc, ni versión de glibc, ni paquetes, y arrancan en FROM scratch. Los de macOS no son estáticos. La plataforma de producción declarada en el proyecto es Linux x86_64 (glibc), según ADR-0001.

# Verificación tras la descarga
shasum -a 256 -c SHA256SUMS.txt --ignore-missing     # macOS
sha256sum -c --ignore-missing SHA256SUMS.txt          # Linux
chmod +x eqproxy-linux-amd64
./eqproxy-linux-amd64 --version

Desde el código fuente, con la toolchain fijada en rust-toolchain.toml (1.99.1, la misma que compila los artefactos de release):

cargo build --release --locked
./target/release/eqproxy --version

Imágenes Docker

Las mismas imágenes se publican en GitHub Container Registry y en Docker Hub, con digests idénticos, para linux/amd64 y linux/arm64:

Las referencias son ghcr.io/exyonq/eqproxy:0.9.1 y exyonq/eqproxy:0.9.1, más la etiqueta móvil :latest, que apunta a la misma imagen que el último release.

La base de ejecución es Wolfi (cgr.dev/chainguard/wolfi-base, fijada por digest), con el binario en /opt/eqproxy, el usuario sin privilegios 65532:65532 y el directorio de estado /var/lib/eqproxy exportado como EQPROXY_STATE_DIR. La imagen expone el puerto 8080 como convención; el proceso escucha donde diga la configuración.

docker pull ghcr.io/exyonq/eqproxy:0.9.1
docker run --rm ghcr.io/exyonq/eqproxy:0.9.1 --version

El entrypoint es /opt/eqproxy: los argumentos que siguen al nombre de la imagen van a la CLI. Sin argumentos, imprime --help.

Requisitos

• Arquitectura: linux/amd64 y linux/arm64 en imagen y binarios; darwin/amd64 y darwin/arm64 solo como binario.
• libc: ninguna en Linux (musl estático); en macOS el binario no es estático.
• Privilegios: ninguno si se escuchan puertos altos; por debajo de 1024 hace falta --user 0 o un mapeo en el host.
• Descriptores: unas 2 FDs por conexión proxificada, más listeners y plano de administración; eqproxy doctor comprueba el presupuesto.
• Ficheros: el TOML y los certificados deben ser legibles por el uid 65532 en la imagen (chmod 644 basta).

Primer arranque

Un eqproxy.toml mínimo: un listener HTTP y un backend.

schema_version = 1

[listener.web]
listen = "0.0.0.0:8080"
mode = "http"
backend = "api"

[backend.api]
server = "127.0.0.1:9000"

./eqproxy-linux-amd64 run --config eqproxy.toml
# o, en contenedor:
docker run --name eqproxy -d -p 8080:8080 \
  -v "$PWD/eqproxy.toml:/etc/eqproxy/eqproxy.toml:ro" \
  ghcr.io/exyonq/eqproxy:0.9.1 run --config /etc/eqproxy/eqproxy.toml

Al arrancar, el proceso escribe INFO listener web listening on 0.0.0.0:8080 en la salida de error y, cada --metrics-interval (30s por defecto), una línea METRICS … con el snapshot de contadores.

Validación por CLI

config validate enlaza nada y no abre puertos: parsea, valida y resuelve el documento completo (certificados, direcciones, balanceo) antes de decir que sí.

./eqproxy-linux-amd64 config validate --config eqproxy.toml
# config OK: 1 listener(s), 1 backend(s) in eqproxy.toml

Los errores salen por la salida de error con fichero, línea, campo, causa y un ejemplo de corrección; la salida es 1. El resto de la CLI:

config apply y config rollback escriben en ./.eqproxy salvo que EQPROXY_STATE_DIR apunte a otro directorio; la imagen ya lo fija en /var/lib/eqproxy.