Plataformas

Ongrid distribuye dos binarios con historias de plataforma muy distintas.

• ongrid (el cloud manager) es una carga Linux + Docker. Está pensado para vivir en un contenedor, detrás de nginx, con MySQL debajo. No hay build first-class para Windows o macOS server.
• ongrid-edge (el agente edge) es un único binario estático que corre en cada host que quieres observar. Cross-compila a cuatro targets de fábrica: Linux en amd64 / arm64 y macOS en amd64 / arm64. Instalación production-grade solo en Linux + systemd; los targets macOS existen para que los desarrolladores puedan correr el agente en su laptop mientras iteran.

Matriz de soporte

Componente	linux/amd64	linux/arm64	darwin/amd64	darwin/arm64	Windows
ongrid (imagen del manager)	sí	testeado como build target	no	no	no
ongrid-edge (binario, supervisado)	sí	sí	dev-only, manual	dev-only, manual	no
plugin promtail (logs)	sí	sí	no (gap upstream)	no (gap upstream)	no
plugin node_exporter (host metrics)	sí	sí	no (gap upstream)	no (gap upstream)	no
plugin process-exporter (proc metrics)	sí	sí	no (gap upstream)	no (gap upstream)	no
plugin otelcol-contrib (trazas)	sí	sí	no (no bundled)	no (no bundled)	no

Los cuatro targets de cross-compile del edge vienen directo del Makefile:

build-edge-linux-amd64
build-edge-linux-arm64
build-edge-darwin-amd64
build-edge-darwin-arm64

make build-edge-all corre los cuatro; make package produce el tarball de release que bundlea cada target más los binarios de plugin Linux-only.

¿Por qué no edge Windows / BSD?

El propio agente es Go puro y compilaría limpio; el gap es el bundle de plugins. promtail, node_exporter, process-exporter y otelcol-contrib todos distribuyen artefactos Linux-only en sus releases upstream. Sin esos cuatro, los paneles de Logs / Monitor / Trazas quedan vacíos incluso después de que el agente conecta. Preferimos no enviar una instalación a medias que llevar una plataforma half-supported escondida.

Si tienes un caso de uso fuerte para Windows o FreeBSD, abre un issue en github.com/ongridio/ongrid — los bundlers pluggables están trackeados bajo ADR-015.

Requisitos del lado cloud

Cualquier lugar donde puedas correr Docker Engine 24+ y Docker Compose v2 alojará el manager. Testeamos en:

• Ubuntu 22.04 LTS, 24.04 LTS
• Debian 12 (bookworm)
• RHEL 9, Rocky Linux 9, AlmaLinux 9

Piso de memoria: 4 GB. Piso de disco: 20 GB (la mayoría retención de Prometheus + Loki, ver Linux (server)).

Requisitos del lado edge

El installer oficial curl-pipe (deploy/install/edge/install.sh) explícitamente solo maneja Linux:

if [[ "$OS" != "linux" ]]; then
    log_error "only linux is supported by this installer; got: $OS"
    exit 1
fi

Ese installer deja una unit systemd (/etc/systemd/system/ongrid-edge.service), crea un usuario de sistema ongrid-edge y supervisa al agente vía systemd con Restart=always. Los hosts macOS pueden seguir corriendo el binario a mano para desarrollo — ver macOS (edge dev) — pero no obtienes el servicio supervisado, el log source journald, ni el bundle de plugins.

Eligiendo la página correcta

• ¿Instalando el manager? → Linux (server)
• ¿Instalando un agente edge en un host Linux real? → Linux (edge)
• ¿Corriendo el agente en un Mac para desarrollo? → macOS (edge dev)
• ¿Desplegando todo en Kubernetes? → Kubernetes
• ¿Air-gapped o registry privado de contenedores? → Air-gapped / on-prem

Política de versionado

El manager y el agente comparten un único archivo VERSION (/Users/.../ongrid/VERSION) y se releasean como un tarball. Un agente edge más viejo que su manager seguirá funcionando: cada RPC del túnel está versionado, y el manager trata los campos de reply desconocidos como valores cero. Un agente edge más nuevo que su manager no está soportado — upgradea el manager primero.

Ver Upgrade para el modelo staged-swap-then-rollback (ADR-024).