Déploiement local

La façon la plus simple d'exécuter Cradle est tout sur une seule machine. Quand vous installez l'application de bureau, elle peut déployer un cradle-server directement là, et le client le pilote via l'API locale. C'est le point de départ recommandé (topologie T0) : le cerveau et l'inférence vivent ensemble, avec le moins de pièces mobiles.

[une machine]
  Cradle (client) ──API──► cradle-server (LlamaCppRunner, GPU/CPU local)

Option A — serveur embarqué (application de bureau)

Installez l'application de bureau. Au premier lancement, elle crée sa base de données dans le répertoire de données OS et bootstrap une clé API admin. Rien d'autre n'est requis — téléchargez un modèle depuis la page Modèles et vous fonctionnez entièrement en local.

C'est idéal pour un seul opérateur sur un poste de travail.

Option B — serveur autonome sur le même hôte

Si vous voulez le daemon headless (par exemple pour le garder ouvert sans l'interface, ou pour pointer plusieurs clients dessus), installez et bootstrap le serveur localement :

# bootstrap la DB et génère une clé admin sans systemd
cradle server init --data-dir /tmp/cradle-local --skip-systemd

# démarre le serveur lié uniquement à localhost
cradle-server --data-dir /tmp/cradle-local --bind 127.0.0.1 --port 31416

Puis pointez un client dessus :

cradle login --url http://127.0.0.1:31416 --key ck_live_...

Liez à 127.0.0.1 pour rester local uniquement. Quand vous êtes prêt à l'exposer à d'autres machines, liez à 0.0.0.0 et mettez un reverse proxy (Caddy ou nginx) devant pour HTTPS — voir déploiement serveur distant.

Quand quitter le local

Un déploiement local suffit pour un seul opérateur et des volumes modestes de messages — le goulot d'étranglement est le modèle sur le GPU, pas la base SQLite embarquée. Passez à un serveur GPU dédié quand vous avez besoin d'une machine partagée à laquelle plusieurs clients se connectent, ou à un service datacenter quand vous avez besoin d'isolation par tenant.