Connexions

Liens internes (service ↔ service, service ↔ stack)

Chaque service ou stack peut être exposé à une adresse interne, puis connecté depuis un autre — sans jamais gérer d’IP, de port public ni de configuration réseau. C’est l’onglet Connexions.

Exposer (producteur) — indiquez le port sur lequel votre application écoute. La plateforme génère une adresse interne stable et redéploie le service pour l’activer. Portée internal (même projet) ou tenant (tout le compte, réservé owner/admin).
Connecter (consommateur) — choisissez une cible parmi les services/stacks exposés, co-localisés et déployés. Trois variables sont injectées automatiquement au déploiement ({PRÉFIXE}_URL, {PRÉFIXE}_HOST, {PRÉFIXE}_PORT) — rien à copier. Si la cible est un service exposé sur Internet, {PRÉFIXE}_PUBLIC_URL donne en plus son adresse publique : c’est celle qu’il faut à une application qui s’exécute dans le navigateur (Element vers son serveur Matrix, avec le préfixe MATRIX). Une connexion peut être posée avant le premier déploiement : ses variables arrivent alors au premier déploiement de la ressource connectée (c’est ce que fait le modèle Matrix).
Copier des variables (options avancées) — dans le formulaire « Connecter », la section Options avancées — variables à copier liste les variables de la cible (noms seulement, jamais les valeurs). Cochez celles que votre ressource doit recevoir ; celles dont le nom ressemble à une variable attendue par votre stack (${VAR} de son compose) sont proposées d’office, sous le nom attendu. Vous pouvez renommer chaque variable côté consommateur. Les valeurs sont relues à chaque déploiement : une valeur modifiée chez la cible est reprise au redéploiement suivant, et une variable supprimée chez elle cesse simplement d’être copiée. Un nom déjà utilisé côté consommateur (variable, binding, autre lien) est refusé.
Révoquer — coupe l’injection et redéploie le consommateur.

Connecter une stack

Pour une stack, la connexion porte sur la VM entière, pas un conteneur en particulier : seul le conteneur exposé de la stack (celui choisi pour le domaine, voir Domaines) est joignable, et les variables injectées atterrissent dans le pool partagé de la stack — tous ses conteneurs y ont accès. Une stack peut aussi bien être consommatrice (elle se connecte à un service ou une autre stack) que productrice (un service ou une autre stack se connecte à elle).

Bindings (service ↔ add-on)

Un binding attache un service à un add-on : la plateforme crée un rôle least-privilege et injecte la chaîne de connexion comme variable d’environnement (ex. DATABASE_URL). La valeur n’est jamais affichée.

Redéploiement — l’application lit sa variable au démarrage : à la connexion, une fenêtre vous prévient, puis le service (ou la stack) est redéployé automatiquement dès que le binding est actif, avec une brève interruption.
Scope — read_only, read_write ou owner (DDL/migrations, réservé aux rôles élevés).
Rotation — régénère le credential et réinjecte la variable, sans interruption de service.
Suppression — révoque le rôle et retire la variable.

Consultation psql éphémère

Pour un accès SQL humain ponctuel, ouvrez un grant de consultation : un rôle Postgres temporaire (VALID UNTIL) avec un credential affiché une seule fois.

L’accès passe par un tunnel SSH éphémère compatible DBeaver, DataGrip, TablePlus… Il est réservé aux rôles owner et admin, et vous devez renseigner l’adresse IP depuis laquelle vous vous connectez (bouton Mon IP, ou l’IP de votre mobile / d’un collaborateur) : elle est la seule à pouvoir ouvrir le tunnel, quel que soit votre réseau. Détails dans Atteindre un service non exposé.

Atteindre un service qui n’est pas exposé

Les liens ci-dessus relient vos ressources entre elles. Pour atteindre un service privé depuis votre poste ou depuis le réseau de votre entreprise, voir Atteindre un service non exposé.

Captures d’écran à insérer.

Les liens sur le canvas

Le canvas du projet dessine chaque lien de service par une flèche en pointillé fin, du service consommateur vers le service producteur. En cliquant n’importe où sur la flèche, vous voyez l’adresse interne du producteur et les noms des variables injectées chez le consommateur (<PRÉFIXE>_URL, _HOST, _PORT, _PUBLIC_URL si le producteur est exposé, plus les variables copiées). Les valeurs ne s’affichent jamais. La révocation se fait depuis l’onglet Connexions du service.

Le clic sur un lien vers un add-on liste de la même façon les variables posées : une seule en mode url, cinq (_HOST, _PORT, _DATABASE, _USER, _PASSWORD) en mode éclaté PostgreSQL.