À propos du projet
Capy est un CLI open source de gestion de secrets sous licence AGPL-3.0, construit avec des primitives de type git pour versionner, synchroniser, déployer et révoquer l'accès aux variables d'environnement d'application, conçu à la fois pour les développeurs humains et les agents de codage IA. Il fonctionne sur une architecture à confiance zéro : les secrets sont chiffrés localement sur la machine de l'utilisateur avant toute synchronisation vers le service hébergé, qui ne stocke que du texte chiffré et des enregistrements d'appartenance à l'équipe. Aucun texte en clair, clé maîtresse ou clé de projet n'est détenu par le service. Le déchiffrement nécessite deux parts de clé distinctes — une retirée par le service, une conservée localement sur l'appareil de l'utilisateur — de sorte qu'une compromission totale du service hébergé ne peut pas exposer les valeurs des secrets. L'installation est disponible via npm, Bun ou Homebrew, avec une version minimale requise de Node.js 18. Le flux de travail principal est conçu pour être peu contraignant : les utilisateurs exécutent `capy` pour synchroniser les secrets, modifient les valeurs soit directement dans le fichier .env (où les valeurs stockées apparaissent sous forme de fragments identifiables `capy:{resourceId}:{ciphertext}`), soit via l'interface TUI interactive lancée avec `capy edit`, puis utilisent `capy run -- <command>` pour injecter les secrets déchiffrés en tant que variables d'environnement pour tout processus qui lit les variables d'environnement. Aucun SDK personnalisé, démon en arrière-plan ou tableau de bord hébergé n'est requis pour exécuter des applications. Les capacités clés incluent : la création de branches de secrets alignées sur git, où Capy maintient des branches de secrets indépendantes épinglées aux branches git correspondantes via un manifeste `keep.lock` commité, afin que les versions de secrets voyagent avec le code ; des contrôles d'accès granulaires par branche pour restreindre l'accès aux secrets de production aux membres autorisés de l'équipe ; la gestion d'équipe via des invitations par e-mail, avec révocation cryptographique immédiate de l'accès pour les utilisateurs supprimés, sans nécessiter de rotation en cascade des clés pour les membres restants ; la prise en charge du déploiement qui guide la configuration pour des plateformes telles que Vercel, Cloudflare, Docker, Fly, Railway, Render, Heroku, GitHub Actions et AWS Lambda, avec prise en charge des workflows CI via des jetons de déploiement générés et des blobs de secrets ; une fonctionnalité hors ligne qui permet à `capy run` de fonctionner à partir d'un cache local après la synchronisation initiale, afin que les applications en cours d'exécution ne soient pas perturbées si le service hébergé est indisponible ; et une migration automatique pour les projets existants, où la première exécution sur un .env en clair chiffre toutes les valeurs, téléverse le texte chiffré, réécrit le .env avec des fragments chiffrés et enregistre une sauvegarde du fichier original. Le CLI inclut un ensemble complet de commandes pour les vérifications d'état, la poussée des modifications locales, le verrouillage des clés locales, l'extraction des identifiants depuis des fournisseurs externes, la rotation des identifiants gérés, la gestion des profils utilisateur, la connexion à des instances Capy auto-hébergées, la configuration de conseils pour les agents de codage IA via AGENTS.md/CLAUDE.md, la récupération de compte et la gestion d'organisation. Le projet maintient une petite empreinte de dépendances d'exécution de seulement cinq paquets (commander, dotenv, inquirer, open, proper-lockfile) afin de réduire la surface d'attaque de la chaîne d'approvisionnement, avec Dependabot configuré pour appliquer des mises à jour hebdomadaires des dépendances. L'outil est gratuit pour les individus et les petites équipes, avec des offres payantes pour les organisations plus grandes, prend en charge le SSO via des fournisseurs d'identité courants, est conforme au RGPD et fait actuellement l'objet d'un audit SOC 2. Le composant de service hébergé est fermé, l'auto-hébergement n'étant pas disponible au lancement.
Comments
0 people shared their preference · Deer Point appears after 10 participants
Sign in to join the discussion.