Déployer Rivet dans un VPC ou un réseau air-gappé

IMPORTANT : Avant de faire quoi que ce soit, vous DEVEZ lire BASE_SKILL.md dans le répertoire de cette skill. Elle contient des orientations essentielles sur le débogage, la gestion des erreurs, la gestion d'état, le déploiement et la configuration du projet. Ces règles et motifs s'appliquent à tous les travaux RivetKit. Tout ce qui suit suppose que vous avez déjà lu et compris cela.

Motifs pour exécuter Rivet auto-hébergé dans un réseau privé : un VPC sans sortie internet, un rack on-premises, ou un environnement complètement air-gappé. Le moteur est un service, le backend de stockage simple nœud recommandé est le système de fichiers local, et le moteur n'établit aucune connexion sortante par défaut. L'auto-hébergement est le seul modèle de déploiement Rivet qui supporte les réseaux air-gappés ; voir Self-Hosting Overview pour la comparaison complète avec BYOC.

Ce qui s'exécute à l'intérieur du périmètre

Un déploiement auto-hébergé a trois composants, qui vivent tous dans votre réseau :

Composant	Rôle	À l'intérieur du périmètre
Votre backend	Votre serveur d'application, incluant le runner qui exécute le code acteur	Oui
Rivet Engine	Service d'orchestration qui gère le cycle de vie des acteurs, achemine les messages et sert le tableau de bord et les API	Oui
Stockage	Persistance pour l'état acteur. Système de fichiers local pour simple nœud, PostgreSQL ou FoundationDB pour multi-nœud	Oui

Il n'y a pas de serveur de licence, pas de compte Rivet Cloud, et aucun rappel vers rivet.dev. Les clients à l'intérieur du périmètre accèdent aux acteurs via la passerelle du moteur sur votre réseau privé. Voir Architecture.

Installation en binaire unique

Le moteur se compile en un binaire unique rivet-engine. Construisez-le à partir de la source en dehors du périmètre, puis copiez le binaire à travers la limite :

git clone https://github.com/rivet-dev/rivet.git
cd rivet
cargo build --release -p rivet-engine
# Copiez target/release/rivet-engine dans le périmètre.

Les binaires pré-compilés arrivent bientôt ; voir Installing Rivet Engine pour les options actuelles.

Exécutez-le avec le backend système de fichiers, qui stocke tout sur disque local et est le choix prêt pour la production pour les déploiements simple nœud. La documentation File System liste les environnements air-gappés comme cas d'usage principal parce qu'il ne nécessite aucune infrastructure de base de données :

RIVET__database__file_system__path="/var/lib/rivet/data" ./rivet-engine

La configuration peut aussi provenir de fichiers. Le moteur découvre la config à /etc/rivet/config.json sur Linux (JSON, JSON5, JSONC, YAML et YML sont tous supportés), et --config surcharge le chemin. Les variables d'environnement utilisent le préfixe RIVET__ avec __ comme séparateur. Voir Configuration.

Le moteur sert son propre tableau de bord sur le port 6420, donc l'inspection et la gestion des namespaces fonctionnent avec rien d'autre qu'un navigateur à l'intérieur du périmètre.

Déploiement Docker Compose

Pour les hôtes Docker sans accès au registre, déplacez l'image du moteur à travers la limite de la façon standard :

# En dehors du périmètre.
docker pull rivetdev/engine:latest
docker save rivetdev/engine:latest -o rivet-engine.tar
# À l'intérieur du périmètre.
docker load -i rivet-engine.tar

Puis exécutez le moteur et votre application ensemble dans un fichier Compose :

services:
  rivet-engine:
    image: rivetdev/engine:latest
    ports:
      - "6420:6420"
    volumes:
      - rivet-data:/data
    environment:
      RIVET__FILE_SYSTEM__PATH: "/data"
    restart: unless-stopped

  my-app:
    build: .
    environment:
      RIVET_ENDPOINT: "http://default:admin@rivet-engine:6420"
    depends_on:
      - rivet-engine
    restart: unless-stopped

volumes:
  rivet-data:

RIVET_ENDPOINT utilise le format http://namespace:token@host:port et dit à votre application de se connecter au moteur en tant que runner au lieu de fonctionner en mode autonome. Après que les deux services démarrent, enregistrez votre runner auprès du moteur via le tableau de bord ou son API. La procédure complète, incluant la configuration PostgreSQL pour les déploiements multi-nœud, est dans Docker Compose.

Pas de télémétrie sortante

Le moteur exporte des traces et des métriques seulement si vous optez pour OpenTelemetry. L'export est désactivé sauf si RIVET_OTEL_ENABLED=1 est défini, et la cible d'export utilise par défaut un collecteur local à http://localhost:4317. Sans configuration, rien ne traverse le périmètre.

Quand vous voulez l'observabilité, gardez-la à l'intérieur du réseau :

Définissez RIVET_OTEL_ENABLED=1 et pointez RIVET_OTEL_GRPC_ENDPOINT vers un collecteur que vous exécutez à l'intérieur du périmètre.
Ajustez RIVET_OTEL_SAMPLER_RATIO pour contrôler l'échantillonnage des traces.
Utilisez le endpoint de santé du moteur pour les sondes de liveness et readiness.

Voir Production Checklist pour des conseils de monitoring.

Intégrer Rivet dans l'environnement d'un client

Si vous livrez un logiciel qui s'exécute dans les VPC de vos clients, le même setup transforme Rivet en composant interne de votre produit plutôt qu'un service que vos clients doivent atteindre sur internet :

Livrez le moteur à côté de votre application. Ajoutez rivetdev/engine au fichier Compose ou chart que vous livrez déjà. Votre application le trouve sur le réseau privé via RIVET_ENDPOINT, donc un artefact déploie toute la pile.
Un namespace par installation. L'URL endpoint porte le namespace et le token (http://namespace:token@host:port), donc une seule image fonctionne sur les déploiements client. Voir Endpoints.
Générez un strong token admin par installation. Remplacez le token par défaut et gardez-le côté serveur. N'incluez jamais le token admin dans RIVET_PUBLIC_ENDPOINT ou nulle part où les clients peuvent le lire.
Public endpoint seulement si nécessaire. RIVET_PUBLIC_ENDPOINT avec un token public (pk_) est requis seulement quand les clients navigateur se connectent aux acteurs en mode runtime serverless. Les déploiements backend uniquement peuvent le sauter entièrement.
TLS à l'edge du client. Terminez TLS avec le reverse proxy ou load balancer du client devant le moteur.

Mise à l'échelle au-delà d'un nœud

Backend	À utiliser quand	Statut
File System (basé sur RocksDB)	Déploiements simple nœud, incluant les installations air-gappées	Prêt pour la production, simple nœud uniquement
PostgreSQL	Déploiements multi-nœud	Recommandé pour multi-nœud aujourd'hui, mais expérimental
FoundationDB	Largest production deployments	Enterprise

Pour les déploiements multi-nœud, exécutez deux ou plusieurs nœuds moteur derrière un load balancer et ajoutez NATS pour la pub/sub, qui remplace le chemin PostgreSQL LISTEN/NOTIFY par défaut à haut débit. Ni l'un ni l'autre n'est nécessaire pour une installation système de fichiers simple nœud. Voir Production Checklist.

Liste de vérification du périmètre

Token admin : Générez un token fort et aléatoire pour l'authentification du moteur et vérifiez qu'il n'est pas exposé aux clients.
Terminaison TLS : Chiffrez les connexions au moteur via un reverse proxy ou un load balancer.
Pas d'exposition publique : Gardez le port 6420 accessible seulement de l'intérieur du périmètre sauf si les clients en dehors en ont réellement besoin.
Health checks : Configurez des sondes de liveness et readiness contre le health endpoint du moteur.
Télémétrie : Laissez l'export OpenTelemetry désactivé, ou pointez-le vers un collecteur à l'intérieur du réseau.
Sauvegardes : Avec le backend système de fichiers, sauvegardez le répertoire de données. Avec PostgreSQL, configurez les sauvegardes automatisées et le failover.

Configuration complète

Self-Hosting Overview pour l'architecture et la comparaison self-host vs BYOC
Installing Rivet Engine pour les installations Docker, binaire et source
Docker Container et Docker Compose pour les déploiements conteneur
Kubernetes pour les déploiements cluster
Configuration pour chaque option et le schéma JSON complet
Endpoints pour connecter votre backend et vos clients
Production Checklist avant de se mettre en ligne

vpc-air-gapped

Déployer Rivet dans un VPC ou un réseau air-gappé

Ce qui s'exécute à l'intérieur du périmètre

Installation en binaire unique

Déploiement Docker Compose

Pas de télémétrie sortante

Intégrer Rivet dans l'environnement d'un client

Mise à l'échelle au-delà d'un nœud

Liste de vérification du périmètre

Configuration complète

Carte de référence

Actors

Agent Os

Clients

Connect

Cookbook

General

Self Hosting

Skills similaires