Plan Local (on-premise)

El Plan Local despliega SHARA en tu propia infraestructura: la base de datos, los agentes y el modelo principal (Concerto) corren en tu casa. Pensado para sectores regulados, cláusulas de soberanía de datos y aislamiento completo respecto a clouds públicas. Esta guía recoge requisitos de hardware por tier, despliegue con Docker Compose, licenciamiento, periodo de gracia, copias de seguridad y soporte on-prem.

Cuándo elegir on-premise

El Plan Local tiene sentido cuando tus datos no pueden salir de tu perímetro: sanidad, sector público, finanzas, defensa o cualquier organización con cláusulas contractuales o normativas (RGPD estricto, secreto profesional, clasificación) que prohíban el tratamiento en clouds de terceros. También es la garantía última de continuidad: si AIGiner dejara de operar, tu despliegue sigue funcionando con Concerto sin depender de nuestros servidores (ver Sin lock-in).

En el resto de planes la inferencia se resuelve en la nube de AIGiner. En Plan Local el grueso de las llamadas se resuelve con Concerto sobre tus propias GPUs, y solo la verificación de licencia y —si la habilitas— la orquestación pesada de Amadeus cloud salen a la red de AIGiner. Apagado el componente cloud, el sistema funciona 100 % offline con soberanía total del dato.

ComponenteDónde corre
Base de datos (tu información)Tu infraestructura
Agentes departamentales y orquestadorTu infraestructura
Concerto (modelo principal)GPUs del cliente
Amadeus cloud (opcional, opt-in)Red de AIGiner, solo si lo habilitas
Servicio de licenciaSolo firma de licencia, sin datos de negocio

Modos de operación

  • Modo aire (air-gapped) — todo se ejecuta 100 % local, sin ninguna llamada a la nube. Soberanía total; Concerto resuelve cada tarea.
  • Modo híbrido — Concerto resuelve el grueso en local y Amadeus cloud sale a la nube solo para las decisiones más complejas que tú autorizas, consumiendo la bolsa de 20 M STU/mes incluida en el contrato (ver STU y cuotas).

Si la bolsa de STU híbrida se agota, el sistema reintenta automáticamente contra Concerto en lugar de bloquear la tarea: el modo híbrido nunca deja de funcionar, solo deja de delegar. Tú decides en la configuración qué clase de tareas pueden salir a la nube; el resto permanece siempre en local.

Requisitos de hardware (por tier)

El instalador detecta RAM y GPU y recomienda automáticamente un tier (umbrales: ≥ 240 GB de RAM → Extended; ≥ 112 GB → Standard; el resto → Compact). Puedes sobreescribir la recomendación al ejecutarlo. Concerto se sirve con mayor *throughput* a mayor tier (cuantización en Compact; precisión completa con paralelismo tensorial en Standard y Extended).

TierRAMGPU (VRAM)CPUDiscoConcurrenciaEncaje
Compact64 GB ECC1 × 24 GB8c/16t mín · 12c/24t rec500 GB–1 TB NVMe~5 usuariosOficina pequeña, un departamento
Standard *(recom.)*128 GB DDR5 ECC2 × 40 GB16c/32t mín · 24c rec1–2 TB NVMe · RAID 1 rec~25 usuariosEmpresa mediana
Extended256 GB (512 rec) por nodo4–8 × 80 GB32c/64t mín · 64c rec4–8 TB NVMe + WAL dedicado100+ usuariosEnterprise / multi-departamento
  • UPS (alimentación ininterrumpida) requerido en Standard y Extended.
  • GPU NVIDIA recomendada en todos los tiers. Sin GPU, Concerto cae a CPU: válido para pruebas, no apto para carga real.
  • Extended exige al menos dos servidores físicos (primario + standby que recibe WAL por streaming) para alta disponibilidad real, más red de clúster dedicada (VLAN/10–100 Gbps).
  • El runtime y los pesos de Concerto por tier se resuelven internamente vía el *registry* de modelos on-prem; no requiere configuración manual salvo indicación de soporte.

Prerrequisitos del host

  • Docker 24+ con el plugin Compose v2.
  • NVIDIA Container Toolkit si el host tiene GPUs.
  • openssl disponible (el instalador genera secretos con openssl rand).
bash
# Docker + Compose v2
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker "$USER"      # cerrar y reabrir sesión
docker compose version

# NVIDIA Container Toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Verificar acceso a GPU desde un contenedor
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

Standard y Extended ajustan además algunos límites de kernel para alta concurrencia:

bash
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
echo 'net.core.somaxconn=4096' | sudo tee -a /etc/sysctl.d/99-shara.conf

Despliegue del stack

Copia el bundle del Plan Local al servidor destino y lanza el *bootstrap*. El instalador detecta el tier, genera los secretos vacíos, prepara el docker-compose.yml y levanta el stack.

bash
# 1. Copiar el bundle al servidor destino
scp -r deployments/plan-local/ user@server:/opt/shara/

# 2. SSH al servidor y lanzar el bootstrap
ssh user@server
cd /opt/shara/plan-local
chmod +x scripts/*.sh
./scripts/install.sh

Qué hace scripts/install.sh, paso a paso:

  1. 1 Detecta RAM/GPU y recomienda el tier (puedes sobreescribirlo).
  2. 2 Copia docker-compose..ymldocker-compose.yml.
  3. 3 Crea .env desde .env.example y rellena los secretos vacíos con openssl rand.
  4. 4 Pide rellenar SHARA_LICENSE_KEY, SHARA_DOMAIN y SHARA_TLS_EMAIL.
  5. 5 Ejecuta docker compose pull y docker compose up -d.
  6. 6 Espera a los *healthchecks* (timeout 5 min) y corre un *smoke test*.

Variables de .env que el operador debe rellenar:

ClaveDescripción
SHARA_LICENSE_KEYClave de activación que entrega AIGiner al firmar contrato. Sin ella el orquestador no arranca.
SHARA_DOMAINHost público. El reverse-proxy emite el certificado TLS. En redes air-gapped, usar nombre interno + TLS interno.
SHARA_TLS_EMAILEmail de contacto para avisos de renovación del certificado.
LICENSING_URLServicio de licencias (https://licensing.aiginer.com).
LICENSING_CHECK_INTERVAL_HOURSIntervalo de verificación de licencia. Default 24.
AMADEUS_CLOUD_URL / AMADEUS_CLOUD_API_KEYVacíos = 100 % on-prem (modo aire). Rellenos = modo híbrido.
SHARA_MULTI_TENANTfalse = una organización (recomendado PYME). true = varios departamentos aislados en la misma instalación.

Componentes que levanta el stack: el motor de inferencia local (alias Concerto), Postgres 17 con tus datos, Redis 7 (colas, *rate-limit*, caché de sesión), el cliente de licencia, el backend de SHARA con el orquestador embebido (1 réplica en Compact, 2 en Standard, 4 en Extended), el reverse-proxy con TLS automático y, según tier, Prometheus + Grafana para observabilidad.

Primer arranque de Concerto: la descarga inicial de los pesos del modelo tarda entre 20 y 40 minutos según el enlace de red; los arranques posteriores reutilizan el volumen local y son inmediatos.

Tras arrancar, apunta el DNS al servidor y verifica el *health probe* público:

bash
# Debe devolver "ok" y los subsistemas en verde
curl https://<tu-dominio>/health

# Estado, logs y operación diaria
docker compose ps                     # estado de cada contenedor
docker compose logs -f shara-backend
docker compose logs -f concerto-llm
docker compose down                   # parar (conserva volúmenes)
scripts/healthcheck.sh                # smoke test in situ

Licenciamiento (Ed25519 + clave de activación)

Cada licencia es un JSON canonicalizado y firmado con Ed25519 (RFC 8032). El cliente local embebe la clave pública y puede verificar la licencia offline; el servicio cloud (licensing.aiginer.com) sigue siendo la autoridad para emitir y revocar. La clave de activación (SHARA_LICENSE_KEY) la entrega AIGiner al firmar el contrato y se introduce en .env.

API pública que puede consumir un cliente o integrador externo:

bash
# Verificar una licencia (público · rate-limit 10 req/min/IP)
curl "https://licensing.aiginer.com/v1/licenses/verify?\
licenseId=<id>&hardwareFingerprint=sha256:<fp>"

# Obtener la clave pública para re-validar manualmente (público)
curl https://licensing.aiginer.com/v1/licenses/public-key

Ejemplo de respuesta de verify. El campo status puede ser active, grace, expired, revoked, hardware_mismatch o not_found. La respuesta incluye responseSignature (cubre licenseId, status y serverTime) para detectar manipulación en tránsito, y serverTime para medir el desfase de reloj:

json
{
  "licenseId": "lic_8f3c...",
  "status": "active",
  "expiresAt": "2027-01-31T23:59:59Z",
  "maxConcurrentUsers": 25,
  "serverTime": "2026-06-15T10:22:31Z",
  "responseSignature": "ed25519:9a1b..."
}
  • El hardwareFingerprint es opcional: omitirlo emite una licencia universal sin atadura a hardware (útil para clústeres HA, donde se confía en expiresAt + maxConcurrentUsers).
  • Si serverTime difiere más de 5 minutos del reloj local, el cliente avisa al administrador (posible *clock skew* o intento de MITM).
  • La verificación offline re-canonicaliza el *payload* con las claves ordenadas alfabéticamente y comprueba la firma Ed25519 contra la clave pública embebida.

Periodo de gracia (30 días) y modo degradado

El cliente de licencia consulta licensing.aiginer.com cada 24 h y guarda el estado. El backend lo lee y rechaza lanzar agentes en estado expired. Si el servidor de licencias está temporalmente inalcanzable, arranca una ventana de gracia de 30 días durante la cual el sistema opera con normalidad (y reintenta cada 1 h en vez de cada 24 h para recuperarse rápido). Si la gracia se agota, el orquestador se bloquea.

Desde el último verify correctoEstadoQué se permite
0–24 hhealthyOperación normal.
24 h – 30 ddegraded (grace)Operación normal + aviso amarillo. Revisar conectividad de salida hacia el servicio de licencias.
30–60 dread-onlySolo lecturas; nuevos *runs*, aprobaciones y cambios de configuración bloqueados. Contactar soporte (urgente).
60 d+ / revocadalockedSolo la consola de administración queda accesible para introducir una licencia válida.
El backend reintenta verificaciones puntuales con *backoff* (2×/4×/8×) sin intervención: en cuanto recupera conectividad con el servicio de licencias, vuelve a healthy automáticamente. Si tu red corporativa filtra el tráfico de salida, añade licensing.aiginer.com a la *allowlist* del firewall.

Backups y retención

  • Standard y Extended ejecutan un *sidecar* de backup que hace pg_dump -F c cada noche y poda los ficheros más antiguos que BACKUP_RETENTION_DAYS (default 30 días).
  • Compact no incluye el *sidecar*: se programa el script manual por cron.
  • Extended añade *streaming* de WAL a un volumen dedicado, habilitando point-in-time recovery (PITR) y *base backups* diarios. El runbook PITR completo se entrega a clientes enterprise vía soporte.
bash
# Backup manual → ./backups/shara-<tier>-<UTC>.dump
scripts/backup.sh

# Cron diario (Compact)
0 3 * * * cd /opt/shara/plan-local && \
  ./scripts/backup.sh >> /var/log/shara-backup.log 2>&1

# Restore (DESTRUCTIVO — recrea la base de datos; pide confirmación salvo --yes)
scripts/restore.sh ./backups/shara-compact-20260615T030000Z.dump

Copia *off-site* según tu política interna (NAS, segundo servidor interno o destino S3-compatible si la política lo permite). Las credenciales de los conectores se cifran y nunca salen de tu infraestructura:

bash
BACKUP_RETENTION_DAYS=30
BACKUP_OFFSITE_KIND=rsync            # rsync | s3 | none
BACKUP_OFFSITE_TARGET=ops@nas.empresa.local:/srv/shara-backups
BACKUP_OFFSITE_ENCRYPTION_KEY=...    # AES-256, cifrado en cliente
# Alternativa S3 directa:
BACKUP_S3_BUCKET=...
BACKUP_S3_REGION=...
BACKUP_S3_ACCESS_KEY=...
BACKUP_S3_SECRET_KEY=...

Actualizaciones

El script de *upgrade* hace, en orden: backup de la base de datos, *pull* de las nuevas imágenes, migraciones y *recreate* del backend. La API es compatible hacia atrás dentro de una *release* menor; los *upgrades* mayores se anuncian en las notas de versión.

bash
scripts/upgrade.sh   # backup → pull → migraciones → recreate del backend

Qué incluye el Plan Local

  • Despliegue inicial acompañado en tu infraestructura.
  • Soporte dedicado y actualizaciones de seguridad.
  • Catálogo de agentes equivalente a Max, con adicionales contratables.
  • 20 M STU cloud/mes para el uso híbrido de Amadeus (opcional).
En Plan Local los logs de auditoría se mantienen en tu propia infraestructura (retención que tú defines) y los *kill-switches* solo afectan al componente Amadeus cloud: Concerto local no factura por uso. Lee STU y cuotas.

Soporte y SLA on-prem

  • Soporte por soporte@aiginer.com24/7, SLA de 4 h de respuesta.
  • Estado de los servicios en https://status.aiginer.com.
  • AIGiner no accede a tu instalación: si hace falta soporte remoto, se establece un túnel WireGuard inverso que controlas tú, temporal y revocable.
¿Quieres una propuesta a medida o un piloto? Mira la página del Plan Local o escribe a hola@aiginer.com.
¿Algo que no encuentras? Escríbenos a hola@aiginer.com.