Auto-héberger OpenConnector avec Docker

Démarrer le runtime

Vous avez besoin de Git et de Docker avec Docker Compose. Commencez par une Action sans authentification avant de configurer un compte d’application. Clonez le dépôt et lancez l’image publiée. Réservez cet essai local à votre propre machine.

git clone https://github.com/oomol-lab/open-connector.git
cd open-connector
docker compose up

Appeler votre première Action

Dans un autre terminal, récupérez les articles populaires de Hacker News. Cette Action en lecture seule ne nécessite aucun compte fournisseur.

curl -s -X POST \
  http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Exécutez cette Action en lecture seule, sans authentification fournisseur, sur un environnement local. Ajoutez votre jeton Bearer si l’authentification du runtime est activée.

Connecter un compte

Ouvrez la console locale, sélectionnez un fournisseur et configurez ses identifiants. Les fournisseurs OAuth nécessitent une application OAuth que vous enregistrez auprès du service.

Conserver et protéger les identifiants

L’image Docker utilise /app/data pour les données locales du runtime. Montez un volume persistant. Configurez OOMOL_CONNECT_ENCRYPTION_KEY pour chiffrer les identifiants stockés et conservez la clé pour la récupération. Consultez le guide avant d’exposer le runtime.

Avant d’exposer un runtime publiquement, configurez l’authentification administrateur, les jetons d’accès, le chiffrement des identifiants et l’origine OAuth publique. Suivez le guide de déploiement pour la production.

Avant d’exposer un déploiement

Le fichier Compose du projet monte connector-data dans /app/data. Avant tout accès distant, configurez séparément OOMOL_CONNECT_ADMIN_TOKEN et OOMOL_CONNECT_RUNTIME_TOKEN, ainsi qu’OOMOL_CONNECT_ENCRYPTION_KEY. Définissez l’origin public et terminez HTTPS à l’entrée du déploiement. Ne versionnez pas les secrets.

Préparer les mises à jour et la restauration

Notez la version de l’image, sauvegardez la base du runtime et conservez une copie sécurisée de sa clé de chiffrement. Testez la restauration dans un environnement isolé avant une mise à jour. Sans la clé, les données chiffrées sont irrécupérables ; supprimer le volume supprime la base locale.

Lire le résultat

Les réponses HTTP du runtime contiennent success, message, data et meta. Vérifiez success et le schéma de sortie de l’Action, pas seulement le statut HTTP. Si les métadonnées contiennent executionId, utilisez-le pour retrouver le journal expurgé correspondant. L’exemple ci-dessous illustre le format ; ce n’est pas un résultat d’appel réel.

{
  "success": true,
  "message": "OK",
  "data": {},
  "meta": {}
}

En cas d’échec

• Pour une erreur d’authentification, vérifiez l’endpoint et le type d’identifiant : l’accès administrateur protège /api, le jeton Bearer runtime autorise /v1 et /mcp. Une clé API fournisseur ne remplace pas le jeton runtime.
• Pour un refus d’accès, vérifiez les scopes requis, les règles d’Actions et les autorisations de connexion. Un jeton valide peut ne pas être autorisé à utiliser le compte choisi.
• Si le résultat est vide ou incomplet, vérifiez le compte connecté et ses droits sur la ressource. Une autorisation réussie ne donne pas accès à tous les espaces, canaux ou documents.
• Consultez l’erreur et le journal avant de réessayer. Si l’Action modifie les données du fournisseur, vérifiez d’abord si elle a déjà abouti ; ne répétez pas la requête aveuglément.