Tout reste dans le périmètre : code, panneau, constats.
Pour les secteurs régulés et les réseaux fermés : le panneau, l'analyse et la base tournent sur vos serveurs. Seules deux portes s'ouvrent vers l'extérieur - le registre d'images et le fichier de licence ; en air-gap, les deux peuvent être portés à l'intérieur.
Un produit, une seule ligne de versions
Chaque installation exécute les mêmes images, versionnées par une seule étiquette. Pas de fork, pas d'édition en retard.
Tous les modules inclus
Tous les modules, d'ArchPilot à Archito, tournent sur vos serveurs. Chaque fonctionnalité arrive à chaque installation dans les mêmes images.
Console d'administration incluse
L'installation a son espace d'administration : licence, utilisateurs et e-mail au même endroit, avec un assistant au premier démarrage.
Identité et IA
Pas de connexion Google ou GitHub : l'identité reste dans votre périmètre, avec e-mail et mot de passe ou LDAP / Active Directory. Les fonctions d'IA sont facultatives et seules elles ont besoin d'Internet, vers le fournisseur choisi par votre opérateur.
Que fait tourner l'installation ?
L'installation de référence compte quatre conteneurs sur un serveur. L'analyse ne tourne pas sur ce serveur mais dans vos jobs de CI.
| Composant | Rôle | Qui y accède |
|---|---|---|
| Panneau (app-ui) | L'interface web qu'ouvrent vos utilisateurs. Elle transmet chaque requête à l'API sous l'identité de l'utilisateur. | Les navigateurs ; port 8080 par défaut |
| API (api) | Reçoit les rapports d'analyse, calcule les scores et exécute les tâches planifiées comme la synchronisation Git et les rapports. C'est le seul composant qui parle à la base de données. | Le panneau et vos runners de CI ; port 5000 par défaut |
| PostgreSQL 16 | Constats, rapports, utilisateurs et paramètres d'administration. | L'API uniquement |
| Redis 7 | Sessions, cache et clés de session partagées entre répliques. | Le panneau et l'API |
| Images d'analyse (collecteurs) | Analysent le code dans votre job de CI et envoient le rapport à votre propre API. Une image pour chacun des neuf langages. | Vos jobs de CI ; rien ne tourne en permanence sur le serveur |
Le TLS est assuré par le reverse proxy (nginx, traefik) ou l'ingress placé devant. Les navigateurs n'ont besoin que du port du panneau, les runners de CI que du port de l'API.
L'installation tient en trois étapes
Kubernetes n'est pas requis ; docker compose suffit. Le guide, captures à l'appui, est sur docs.apparch.io.
- 01
Licence + clé d'installation
Les ventes envoient votre ID d'installation et la clé d'installation ; la clé n'est transmise qu'une seule fois. Au premier démarrage, l'installation récupère sa licence en ligne. En air-gap, vous envoyez le code d'installation affiché par l'assistant et recevez un fichier .lic lié à ce code.
- 02
Récupérez les images
docker login hub.apparch.io - l'ID d'installation est l'identifiant, la clé le mot de passe. Sur un réseau air-gap, les images sont tirées une fois dehors puis portées dedans.
- 03
compose up + assistant
Le fichier compose démarre le panneau, l'analyse et les migrations de base ; au premier lancement, l'assistant relie le compte admin et la licence.
Prérequis : Docker Engine 24+ avec le plugin compose. C'est tout.
Installer sur un réseau isolé
Ni l'installation ni l'exploitation n'ont besoin d'une connexion vers l'extérieur. Le seul échange avec le dehors : deux fichiers transportés à la main.
- 01
Faire entrer les images
Les images du panneau et de l'API sont livrées dans un seul fichier d'archive ; vous le portez sur le serveur et le chargez avec docker load. Les images d'analyse vont dans votre propre registre interne, d'où vos jobs de CI les tirent.
- 02
Générer les secrets sur le serveur
gen-secrets.sh crée au hasard, sur le serveur lui-même, les mots de passe de la base et de Redis, la clé de signature des sessions et la clé maîtresse de chiffrement. Aucun ne nous parvient, aucun n'est dans les images.
- 03
Envoyer le code d'installation
Démarrez les services et envoyez à AppArch le code d'installation affiché à l'étape licence de l'assistant. Le fichier .lic reçu en retour n'est lié qu'à cette installation ; placez-le dans ./license/apparch.lic ou collez-le dans l'assistant.
- 04
Aucune requête ne sort
Laissez vides les adresses du fournisseur et des mises à jour : la licence est vérifiée en local, aucune vérification de version n'a lieu et aucune requête ne quitte le réseau. Les nouvelles versions arrivent elles aussi sous forme de fichiers.
Simple à exploiter, clair à surveiller
Ce que votre équipe doit savoir après l'installation, en quatre points.
Points de santé
/health/live indique que le processus tourne, /health/ready que la base et Redis répondent (pour le panneau : l'API). Compose s'en sert comme healthchecks de conteneur ; sous Kubernetes, ils alimentent les sondes liveness et readiness.
Mises à niveau
Changez la version d'image dans .env, puis docker compose pull et up. Les migrations en attente s'appliquent au démarrage, dans l'ordre, quel que soit le nombre de versions sautées. Elles ne vont que vers l'avant : faites d'abord une sauvegarde pg_dump.
Un démarrage qui s'explique
L'API journalise son démarrage étape par étape : base de données, migrations, données de référence, licence. Si une étape échoue, la ligne d'erreur nomme l'étape ; un échec de connexion affiche l'hôte et le port, jamais les identifiants.
Plusieurs répliques
Des répliques partageant le même PostgreSQL et le même Redis forment une seule installation : les migrations s'exécutent une fois sous un verrou de base, les tâches planifiées se déclenchent sur une seule réplique via un planificateur en cluster, les sessions sont partagées par Redis.
Sécurisé par défaut
Des mesures fournies avec l'installation, sans configuration supplémentaire.
- Vos secrets restent chez vous. Mots de passe et clés sont générés sur votre serveur lors de l'installation ; les images ne contiennent que des valeurs par défaut non secrètes.
- Identifiants Git chiffrés. Les jetons d'accès des fournisseurs connectés sont chiffrés en base avec AES-GCM sous la clé maîtresse de votre installation.
- Images sans shell, sans root. Les conteneurs n'embarquent que le runtime .NET, aucun shell, et tournent sous un utilisateur non privilégié.
- Une licence non modifiable. La licence est vérifiée avec la clé de signature AppArch intégrée aux images ; modifier le fichier à la main casse la signature.
- La connexion reste dans votre réseau. E-mail et mot de passe (avec authentification à deux facteurs facultative) ou LDAP / Active Directory. Pas de connexion via Google ou GitHub.
Comment se comporte la licence ?
Pas d'arrêt surprise : les limites sont explicites, tout comme ce qui se passe au-delà.
Un fichier signé, vérifié hors ligne
La licence est un fichier .lic signé RS256 ; l'installation le vérifie localement, et une licence ne fonctionne que sur une seule installation. Elle ne téléphone pas à un serveur de licences pour tourner. Plusieurs pods partageant une même base de données comptent comme une seule installation.
Compteurs au mois civil
Les limites d'usage se comptent par mois civil et se réinitialisent en début de mois - pas de surprise de fenêtre glissante.
Limite souple d'abord, stricte ensuite
Dépasser une limite n'arrête pas le travail : sept jours et 10 % sont tolérés pendant que le panneau vous avertit. L'arrêt strict n'arrive qu'une fois ce tampon épuisé.
Questions fréquentes
Comment recevoir les mises à jour ?
Quelles options d'authentification ?
En air-gap total, qu'est-ce qui marche ou pas ?
Qui voit les données ?
Comment fonctionne la tarification ?
Fonctionne-t-il sur Kubernetes ?
Que dois-je sauvegarder ?
Que devient la licence si je change de serveur ?
Essayez-le dans votre périmètre
Demandez votre ID d'installation ; avec le fichier compose, vous êtes debout en un après-midi.