Concerto Local (on-premise)

Concerto Local (custom pricing: talk to sales) runs Shara on your own infrastructure: the database, the agents and the main model (Concerto) live on your server. This guide covers what you need, how to install it, how to connect it to your Shara account and how to look after it.

Who installs it

There are two ways, and both are included in the contract:

We install it for you. Installation is included when you sign up for Concerto Local. We do it on site or remotely and leave it running and connected to Shara. You do not need to do anything below.
Your IT team installs it. If your company has an IT team and prefers to do it itself, it is a one-command installer on top of Docker. The rest of this guide goes step by step, in short sentences, with commands you can copy as they are.

To install it yourself you need three items that AIGiner hands over with the contract: the download address (<URL>), the download token (<TOKEN>) and, where it applies, the address of the models file (<URL-MODELOS>). Without them it cannot be installed. If you do not have them, write to sales@aiginer.com.

What you need

The server

Concerto Local is for a company server with GPUs and runs on Linux x86_64 (not ARM). It is a single server, with these requirements:

Requirement	Minimum
Graphics	8 NVIDIA H200-class GPUs (141 GB each) or higher (B200 or B300)
Memory	At least 512 GB of RAM
Processor	64 cores
Disk	2 TB of free NVMe
System	Linux with Docker and the NVIDIA driver

Below these requirements the installer will not install.
We also support private-cloud deployments (AWS, Azure or GCP), with dedicated GPU machines inside your own account.

Software, disk and network

Docker 24 or later with the Compose plugin. If it is missing, the installer installs it (with --si), or you can install it first.
NVIDIA driver and NVIDIA Container Toolkit. If missing, the installer says so and stops before touching anything.
Free disk in /opt: at least 2 TB of NVMe.
The server can reach the Internet (the first time it downloads the image and the model weights).
Ports 80 and 443 are free.
A name to sign in with (for example shara.company.com) pointing at the server. A public name is not required: the installer uses the machine’s internal name and browsers will warn about the certificate.

Check the server

What	Command	What to look for
System	`uname -sm`	It must say `Linux x86_64`.
Memory	`free -g`	The “total” figure must be 512 GB or more.
Graphics card	`nvidia-smi`	It must list 8 GPUs of H200 class or higher. If it fails, there is no NVIDIA driver or card.
Free disk	`df -h /opt`	At least 2 TB of free NVMe.

And that ports 80 and 443 are free: this command must return nothing.

sudo ss -ltnp | grep -E ':80 |:443 '

To check whether the server meets the requirements, without installing anything:

curl -fsSL <URL>/instalar.sh | bash -s -- --solo-comprobar

The lines that matter are RAM_GB=... and GPU_NUM=.... If the server does not meet the requirements, the installer says so and does not install.

Install with one command

Replace <URL>, <TOKEN>, <URL-MODELOS> (the contract details), the domain and the email:

curl -fsSL <URL>/instalar.sh | sudo SHARA_IMAGEN_URL=<URL>/imagen.tar.zst SHARA_PAQUETE_URL=<URL>/paquete.tar.zst SHARA_MODELOS_URL=<URL-MODELOS> SHARA_DESCARGA_TOKEN=<TOKEN> bash -s -- --dominio shara.company.com --email it@company.com --si

--dominio and --email are for the certificate. If you leave them out, the machine name is used.
--si answers “yes” to the questions (for example, installing Docker if it is missing). Leave it out if you would rather be asked.
--dir /opt/shara moves the installation to another folder.

The installer, in order: checks the server, installs Docker if missing, creates the configuration with random keys, loads the Shara image, starts everything and waits for it to answer. Then it installs automatic start-up and the shara-local command.

The first time takes a while. It downloads the model weights, about 760 GB: a couple of hours on a 1 Gb/s line and much longer on a slower one, printing dots as it goes. If the SSH connection drops, the installation carries on; sign in again and check the status. Running the command again is safe: it does not change the keys or touch the data.

Check that it works

shara-local estado

It must end with “Todo está en marcha.” and the version line. The shara-migrate and concerto-bootstrap services show as “Exited (0)”: that is normal, they only work at start-up.

Then, from a browser:

Open https://<your-domain>/livez. It must show {"status":"alive"}.
Open https://<your-domain>. The Shara sign-in screen must appear.

The certificate fingerprint

The server signs with its own authority and the desktop app pins the certificate the first time it connects. Check that it is yours. On the server:

sudo shara-local estado

prints a line “Huella del certificado: FF:DE:…:A0” (SHA-256 in hexadecimal, upper case, separated by colons). In the app, when you choose “My company’s server”, another fingerprint is shown: they must be identical, character by character. If they are not, do not go on: someone may be in the middle of the connection.

The certificate is your own, valid for 10 years, and the installer creates it only once in /opt/shara/nginx/certs/. It does not change on reboot or on update.
Do not delete that folder: the app would see a different server and block the connection.
The app only accepts https (and http only towards localhost).
If the browser warns about the certificate and there is no public domain, that is expected. Ask IT to install the root certificate, or use a company certificate.

Also test a restart with sudo reboot. A few minutes later, shara-local estado must say the same, without you doing anything.

Connect to Shara

The server works on its own, but to have your Shara account see and manage it you have to connect it.

Sign in to the Shara app with the owner or administrator account, open the Local Plan section and ask for a connection code.
An 8-character code appears (XXXX-XXXX). It is valid for 15 minutes and works once. If you ask for another, the previous one stops working.
On the server:

sudo shara-local conectar XXXX-XXXX

If it says “Conectado”, you are done. The connection is stored in /opt/shara/conexion/conexion.json (readable only by root) and, within 30 seconds, Shara shows the server as connected.

If it fails:

Message	What it means
“no acepta ese código”	It does not exist, was already used or 15 minutes have passed. Create a new one in Shara.
“Demasiados intentos”	Wait a minute and try again.
“respuesta 404”	The activation service is not available yet. It is not your fault: tell AIGiner.
“no he podido llegar”	The server cannot reach the Internet.

From then on the shara-conector service keeps the connection for good: it pings Shara every 30 seconds, renews the licence by itself and, if the Internet or the cloud goes down, reconnects on its own (it waits 1 s, 2 s, 4 s… up to 5 minutes between attempts). shara-local estado tells you how it is going, and shara-local logs shara-conector gives the detail. Without Internet nobody can sign in or renew their session, because both go through the Shara cloud. The server holds on with the licence for 30 days of grace (see below); your data, the agents and the model stay on your server.

Disconnect. From Shara, in the Local Plan section, with the option to disconnect the server. The connector logs it (“4401”) and stops retrying; the server keeps working locally. To connect it again, create a new code and use shara-local conectar: nothing needs restarting. Running conectar again is safe, it overwrites the previous connection.

Licence and days offline

The licence is valid for 7 days and the connector renews it daily.
If it expires (for example, because the server has been without Internet for days), there are 30 days of grace. During grace the app warns you with the X-Shara-Licencia header and in GET /v1/plan-local/estado-local.
After the grace period, or with no licence, the server still lets you read and export your data (/tenants/me/export, /me/data-export), but rejects with 402 licencia_caducada anything that writes or runs agents, over WebSocket too.
Getting the connection back is enough to return to normal: the connector renews the licence by itself.

The clock

The server stores the last instant it has seen and never moves it backwards, so that setting the date back does not extend the licence. As a result, if the clock jumped forward by mistake (motherboard battery, a wrong date for a while), the licence would be treated as past even though it is not. To repair it:

sudo shara-local reparar-reloj

It requires the clock to be synchronised over NTP (timedatectl show -p NTPSynchronized must say yes), shows the stored instant and the current time, asks you to type REPARAR and leaves a record in the audit trail. It only lowers the instant to the current time; it never raises it.

If the power goes out

Do nothing special. Wait 5 minutes: the server boots and Shara starts by itself. Check with shara-local estado. If after 10 minutes something has not come back:

sudo shara-local arrancar
shara-local estado

The database recovers by itself after a cut. With a UPS the risk is almost zero: we always recommend one.

Update

sudo shara-local actualizar

It first makes a backup, loads the new version and restarts. Database migrations run by themselves. It takes a few minutes and Shara does not respond during that time.

Backups

Make one now:

sudo shara-local copia

They are stored in /opt/shara/copias and those older than 30 days are deleted. Copy that folder to another machine from time to time: a backup on the same disk is no use if the disk dies.

Go back to a backup (it overwrites the current data, and asks for confirmation before deleting anything):

sudo shara-local restaurar /opt/shara/copias/<file>.dump

Stop, start and read the logs

sudo shara-local parar         # stops Shara; the data is kept
sudo shara-local arrancar
sudo shara-local reiniciar
shara-local logs               # everything; Ctrl+C to leave
shara-local logs shara-backend # a single service

Uninstall

sudo shara-local desinstalar

It asks first. It removes automatic start-up and stops Shara, but keeps the data and the backups. To delete the data too (there is no way back):

sudo shara-local desinstalar --borrar-datos

It also asks you to type BORRAR. Without --borrar-datos nothing is deleted.

Common problems

What you see	What to do
“Hace falta arquitectura x86_64”	The server is ARM. Local Plan only runs on x86_64.
“Falta Docker 24+”	Run it again with `--si` and it installs it, or install it by hand and run it again.
“Hay GPU pero falta NVIDIA Container Toolkit”	Install it (NVIDIA’s “Container Toolkit” guide) and run it again.
“No tengo los pesos de Concerto…”	The models file is missing. Pass `SHARA_MODELOS_URL` or copy the file to `/opt/shara/modelos.env`.
“No se pudo descargar…”	Token copied wrongly, or the server cannot reach the Internet. Try `curl -I <URL>/instalar.sh`.
Time passes and “todavía no está sano”	Waiting is normal the first time. Look at `shara-local logs concerto-llm`: if it is still downloading, wait.
`shara-local estado` flags something “unhealthy”	`shara-local logs <service>` and send the last 50 lines to AIGiner.
The browser warns about the certificate	Expected without a public domain. See “The certificate fingerprint”.
Port 80 or 443 is taken	Another web server (Apache, Nginx) is running. Stop it or install Shara on another machine.
Much slower than expected	The server is not performing as it should. Review “What you need” (GPU, memory and disk) and talk to AIGiner.

When you ask AIGiner for help (support@aiginer.com), always send the output of shara-local estado, the version (cat /opt/shara/VERSION) and the last 50 lines of the failing service. Never send the .env file or the conexion/ folder: they hold keys.

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