Skip to content

Concerto Local (on-premise)

Concerto Local (€999/month) deploys Shara entirely on your own infrastructure: the database, the agents and the main model (Concerto) run at your place, with no cloud component whatsoever. Built for regulated sectors, data sovereignty clauses and complete isolation from public clouds. Everything included. This guide covers the three hardware tiers, Docker Compose deployment, licensing, the grace period, backups and on-prem support.

Concerto Local makes sense when your data can’t leave your perimeter: healthcare, public sector, finance, defense or any organization with contractual or regulatory clauses (strict GDPR, professional secrecy, classification) that prohibit processing in third-party clouds. It’s also the ultimate continuity guarantee: if AIGiner were to stop operating, your deployment keeps working with Concerto with no dependence on our servers (see No vendor lock-in).

On every other plan, inference is resolved in the cloud. On Concerto Local every call is resolved with Concerto on your own GPUs: there’s no cloud component, no cloud delegation and no STU quota. Only the periodic license check contacts AIGiner’s network (with no business data). The system runs 100% on-premise with full data sovereignty.

ComponentWhere it runs
Database (your information)Your infrastructure
Departmental agents and orchestratorYour infrastructure
Concerto (main model)Client GPUs
Licensing serviceLicense signing only, no business data

Everything runs 100% locally, with no inference call going to the cloud. Full sovereignty: Concerto resolves every task on your infrastructure, including the orchestration of the main agent.

Concerto Local adapts to three tiers based on the client’s infrastructure. The installer detects RAM and GPU and automatically recommends the tier; you can override the recommendation when running it. Each tier serves a Concerto model (alias) sized to the available hardware: quantized on Compact, full precision with tensor parallelism on Standard and Extended.

TierRAMGPU (VRAM)CPUDiskConcurrencyFit
Concerto Compact16 GBIntegrated / optional8c/16t min · 12c/24t rec500 GB to 1 TB NVMe~5 usersSmall office, one department
Concerto Standard (recommended)64 GB DDR51 × 24 GB (RTX 4090 class)16c/32t min · 24c rec1 to 2 TB NVMe · RAID 1 rec~25 usersMid-sized company
Concerto Extended256 GB (512 rec) per nodeData-center GPU server32c/64t min · 64c rec4 to 8 TB NVMe + dedicated WAL100+ usersEnterprise / multi-department
  • UPS (uninterruptible power supply) recommended on Standard and required on Extended.
  • Concerto Compact works with just 16 GB of RAM and integrated or optional GPU: built for small teams. A dedicated GPU improves throughput but isn’t essential at this tier.
  • Concerto Extended requires a data-center GPU server (at least two physical nodes: primary + standby receiving WAL over streaming) for real high availability, plus a dedicated cluster network (VLAN/10 to 100 Gbps).
  • The Concerto runtime and weights per tier are resolved internally via the on-prem model registry; no manual configuration is needed unless support instructs otherwise.
  • Docker 24+ with the Compose v2 plugin.
  • NVIDIA Container Toolkit if the host has GPUs.
  • openssl available (the installer generates secrets with openssl rand).
bash
# Docker + Compose v2
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker "$USER"      # log out and back in
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

Concerto Standard and Extended also tune some kernel limits for high concurrency:

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

Copy the Concerto Local bundle to the target server and run the bootstrap. The installer detects the tier, generates empty secrets, prepares docker-compose.yml and brings up the 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

What scripts/install.sh does, step by step:

  1. Detects RAM/GPU and recommends the tier (you can override it).
  2. Copies docker-compose.<tier>.ymldocker-compose.yml.
  3. Creates .env from .env.example and fills the empty secrets with openssl rand.
  4. Asks you to fill in SHARA_LICENSE_KEY, SHARA_DOMAIN and SHARA_TLS_EMAIL.
  5. Runs docker compose pull and docker compose up -d.
  6. Waits for the healthchecks (5 min timeout) and runs a smoke test.

.env variables the operator must fill in:

KeyDescription
SHARA_LICENSE_KEYActivation key AIGiner provides upon signing the contract. Without it, the orchestrator won’t start.
SHARA_DOMAINPublic host. The reverse proxy issues the TLS certificate. On air-gapped networks, use an internal name + internal TLS.
SHARA_TLS_EMAILContact email for certificate renewal notices.
LICENSING_URLLicensing service (https://licensing.aiginer.com).
LICENSING_CHECK_INTERVAL_HOURSLicense check interval. Default 24.
SHARA_MULTI_TENANTfalse = single organization (recommended for SMEs). true = several isolated departments on the same install.

Components the stack brings up: the local inference engine (alias Concerto), Postgres 17 with your data, Redis 7 (queues, rate-limit, session cache), the license client, Shara’s backend with the orchestrator embedded (1 replica on Compact, 2 on Standard, 4 on Extended), the reverse proxy with automatic TLS and, depending on tier, Prometheus + Grafana for observability.

First Concerto start-up: the initial download of the model weights takes 20 to 40 minutes depending on the network link; subsequent start-ups reuse the local volume and are immediate.

After start-up, point the DNS at the server and check the public health probe:

bash
# Should return "ok" with every subsystem green
curl https://<your-domain>/health

# Status, logs and day-to-day operation
docker compose ps                     # status of each container
docker compose logs -f shara-backend
docker compose logs -f concerto-llm
docker compose down                   # stop (keeps volumes)
scripts/healthcheck.sh                # on-site smoke test

Each license is a canonicalized JSON payload signed with Ed25519 (RFC 8032). The local client embeds the public key and can verify the license offline; the cloud service (licensing.aiginer.com) remains the authority to issue and revoke. AIGiner provides the activation key (SHARA_LICENSE_KEY) when the contract is signed, and it’s entered into .env.

Public API a client or external integrator can consume:

bash
# Verify a license (public · rate-limit 10 req/min/IP)
curl "https://licensing.aiginer.com/v1/licenses/verify?\
licenseId=<id>&hardwareFingerprint=sha256:<fp>"

# Get the public key to re-validate manually (public)
curl https://licensing.aiginer.com/v1/licenses/public-key

Example verify response. The status field can be active, grace, expired, revoked, hardware_mismatch or not_found. The response includes responseSignature (covering licenseId, status and serverTime) to detect in-transit tampering, and serverTime to measure clock skew:

json
{
  "licenseId": "lic_8f3c...",
  "status": "active",
  "expiresAt": "2027-01-31T23:59:59Z",
  "maxConcurrentUsers": 25,
  "serverTime": "2026-06-15T10:22:31Z",
  "responseSignature": "ed25519:9a1b..."
}
  • The hardwareFingerprint is optional: omitting it issues a universal license with no hardware binding (useful for HA clusters, which rely on expiresAt + maxConcurrentUsers).
  • If serverTime differs by more than 5 minutes from the local clock, the client alerts the administrator (possible clock skew or MITM attempt).
  • Offline verification re-canonicalizes the payload with alphabetically ordered keys and checks the Ed25519 signature against the embedded public key.

The license client checks licensing.aiginer.com every 24 h and stores the status. The backend reads it and refuses to launch agents when status is expired. If the licensing server is temporarily unreachable, a 30-day grace window starts, during which the system operates normally (and retries every 1 h instead of every 24 h to recover fast). If the grace period runs out, the orchestrator locks.

Since the last successful verifyStatusWhat’s allowed
0 to 24 hhealthyNormal operation.
24 h to 30 ddegraded (grace)Normal operation + yellow warning. Check outbound connectivity to the licensing service.
30 to 60 dread-onlyReads only; new runs, approvals and configuration changes blocked. Contact support (urgent).
60 d+ / revokedlockedOnly the admin console stays accessible to enter a valid license.

The backend retries verification with backoff (2×/4×/8×) with no manual intervention: as soon as it regains connectivity with the licensing service, it goes back to healthy automatically. If your corporate network filters outbound traffic, add licensing.aiginer.com to the firewall allowlist.

  • Concerto Standard and Extended run a backup sidecar that does pg_dump -F c every night and prunes files older than BACKUP_RETENTION_DAYS (default 30 days).
  • Concerto Compact doesn’t include the sidecar: the manual script is scheduled via cron.
  • Concerto Extended adds WAL streaming to a dedicated volume, enabling point-in-time recovery (PITR) and daily base backups. The full PITR runbook is provided to enterprise clients via support.
bash
# Manual backup → ./backups/shara-<tier>-<UTC>.dump
scripts/backup.sh

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

# Restore (DESTRUCTIVE: recreates the database; asks for confirmation unless --yes)
scripts/restore.sh ./backups/shara-compact-20260615T030000Z.dump

Off-site copy according to your internal policy (NAS, second internal server or an S3-compatible destination if policy allows it). Connector credentials are encrypted and never leave your infrastructure:

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=...

The upgrade script does, in order: a database backup, pulling the new images, migrations and recreating the backend. The API is backward compatible within a minor release; major upgrades are announced in the release notes.

bash
scripts/upgrade.sh   # backup → pull → migraciones → recreate del backend
  • Everything included for €999/month: no STU fees, no overage, no cloud component.
  • Initial deployment guided on your infrastructure.
  • Dedicated support and security updates.
  • The full agent catalog: all 20 departmental agents included, at no extra charge for any of them.
  • Unlimited on-premise inference: Concerto runs on your GPUs, with no billing by use.

On Concerto Local, audit logs are kept on your own infrastructure (retention that you define) and inference doesn’t bill by use: there are no STU or spending kill-switches because there’s no cloud component. Read STU and quotas.

  • Support via support@aiginer.com: 24/7, 4h response SLA.
  • Service status at https://status.aiginer.com.
  • AIGiner doesn’t access your installation: if remote support is needed, a reverse WireGuard tunnel is set up that you control, temporary and revocable.

Want a tailored proposal or a pilot? Write to hello@aiginer.com.

Questions about plans, pricing or billing? Write to us at sales@aiginer.com.