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.
| Componente | Dónde corre |
|---|---|
| Base de datos (tu información) | Tu infraestructura |
| Agentes departamentales y orquestador | Tu infraestructura |
| Concerto (modelo principal) | GPUs del cliente |
| Amadeus cloud (opcional, opt-in) | Red de AIGiner, solo si lo habilitas |
| Servicio de licencia | Solo 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).
| Tier | RAM | GPU (VRAM) | CPU | Disco | Concurrencia | Encaje |
|---|---|---|---|---|---|---|
| Compact | 64 GB ECC | 1 × 24 GB | 8c/16t mín · 12c/24t rec | 500 GB–1 TB NVMe | ~5 usuarios | Oficina pequeña, un departamento |
| Standard *(recom.)* | 128 GB DDR5 ECC | 2 × 40 GB | 16c/32t mín · 24c rec | 1–2 TB NVMe · RAID 1 rec | ~25 usuarios | Empresa mediana |
| Extended | 256 GB (512 rec) por nodo | 4–8 × 80 GB | 32c/64t mín · 64c rec | 4–8 TB NVMe + WAL dedicado | 100+ usuarios | Enterprise / 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.
openssldisponible (el instalador genera secretos conopenssl rand).
# 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:
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.
# 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 Detecta RAM/GPU y recomienda el tier (puedes sobreescribirlo).
- 2 Copia
docker-compose.→.yml docker-compose.yml. - 3 Crea
.envdesde.env.exampley rellena los secretos vacíos conopenssl rand. - 4 Pide rellenar
SHARA_LICENSE_KEY,SHARA_DOMAINySHARA_TLS_EMAIL. - 5 Ejecuta
docker compose pullydocker compose up -d. - 6 Espera a los *healthchecks* (timeout 5 min) y corre un *smoke test*.
Variables de .env que el operador debe rellenar:
| Clave | Descripción |
|---|---|
SHARA_LICENSE_KEY | Clave de activación que entrega AIGiner al firmar contrato. Sin ella el orquestador no arranca. |
SHARA_DOMAIN | Host público. El reverse-proxy emite el certificado TLS. En redes air-gapped, usar nombre interno + TLS interno. |
SHARA_TLS_EMAIL | Email de contacto para avisos de renovación del certificado. |
LICENSING_URL | Servicio de licencias (https://licensing.aiginer.com). |
LICENSING_CHECK_INTERVAL_HOURS | Intervalo de verificación de licencia. Default 24. |
AMADEUS_CLOUD_URL / AMADEUS_CLOUD_API_KEY | Vacíos = 100 % on-prem (modo aire). Rellenos = modo híbrido. |
SHARA_MULTI_TENANT | false = 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:
# 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:
# 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:
{
"licenseId": "lic_8f3c...",
"status": "active",
"expiresAt": "2027-01-31T23:59:59Z",
"maxConcurrentUsers": 25,
"serverTime": "2026-06-15T10:22:31Z",
"responseSignature": "ed25519:9a1b..."
} - El
hardwareFingerprintes opcional: omitirlo emite una licencia universal sin atadura a hardware (útil para clústeres HA, donde se confía enexpiresAt+maxConcurrentUsers). - Si
serverTimedifiere 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 correcto | Estado | Qué se permite |
|---|---|---|
| 0–24 h | healthy | Operación normal. |
| 24 h – 30 d | degraded (grace) | Operación normal + aviso amarillo. Revisar conectividad de salida hacia el servicio de licencias. |
| 30–60 d | read-only | Solo lecturas; nuevos *runs*, aprobaciones y cambios de configuración bloqueados. Contactar soporte (urgente). |
| 60 d+ / revocada | locked | Solo 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 ahealthyautomáticamente. Si tu red corporativa filtra el tráfico de salida, añadelicensing.aiginer.coma la *allowlist* del firewall.
Backups y retención
- Standard y Extended ejecutan un *sidecar* de backup que hace
pg_dump -F ccada noche y poda los ficheros más antiguos queBACKUP_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.
# 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:
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.
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.com— 24/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.