Projets

Un projet est un dépôt git ou un dossier sur le serveur. L’agent en tient un registre, et l’app affiche ce que dit le registre. Rien n’est deviné.

En ajouter un

« Nouveau projet », sur le tableau de bord ou dans la barre latérale. Donnez une URL git ou pointez un dossier qui existe déjà sous le dossier des projets ; l’agent lit la source avant de déclarer quoi que ce soit — le gestionnaire de paquets qu’elle verrouille, le script qui la démarre, le port qu’elle demande s’il est libre — et le formulaire propose le reste : un nom tiré de l’adresse, un port qu’aucun projet déclaré ne tient, la commande de démarrage. Tout reste modifiable ; le serveur décide de ce qu’il accepte et le dit. Une fois créé, l’agent :

1. clone le dépôt dans votre dossier de projets, ou adopte le dossier ;
2. détecte le gestionnaire de paquets et installe les dépendances ;
3. lit la commande de démarrage que le projet déclare ;
4. le démarre dans une session tmux nommée d’après le projet ;
5. rapporte le port sur lequel il écoute, l’URL, et le flux de logs.

Si une étape a besoin de quelque chose qui manque — un runtime non installé, une base que le projet attend — elle le dit et nomme le module qui le fournit.

Où il vit

Les projets vivent sous le dossier choisi pendant core.system, un dossier par projet, appartenant à dev. Le registre enregistre le chemin absolu : un projet déplacé à la main reste un projet que l’agent retrouve.

Démarrer et arrêter

Le démarrage et l’arrêt passent par tmux. C’est délibéré : un projet continue de tourner quand vous fermez l’app, quand votre laptop s’endort, et quand votre connexion tombe. Rouvrez l’app, elle se rattache à la même session avec le même historique.

Logs

L’app diffuse la sortie de la session telle que l’agent la lit. L’historique est celui de tmux ; rien n’est mis en tampon sur la plateforme, et rien n’est stocké ailleurs que sur la machine.

Fichiers d’environnement

Si tool.1password est installé, un projet qui porte un template .env.local voit son fichier généré depuis votre coffre au démarrage. Sans lui, vous gérez vos fichiers d’environnement vous-même, dans le dossier, comme partout ailleurs.

Variables fournies par Pupitre

Chaque projet reçoit ce que Pupitre sait de lui dans des variables PUPITRE_* : son port, ses adresses locale et publique, celles de ses autres processus, le domaine du serveur. Un script les lit au lieu de les écrire en dur, et quand vous publiez une route ou changez de domaine dans l’app, le projet suit sans qu’on touche au code.

Variable	Valeur
PUPITRE	1, partout sur le serveur
PUPITRE_PROJECTS_DIR	la racine des projets
PUPITRE_DOMAIN	le domaine publié, absent sans exposition
PUPITRE_PROJECT, PUPITRE_PROJECT_DIR, PUPITRE_PROJECT_URL	le nom, le dossier et l’adresse du projet
PUPITRE_PROCESS_<ID>_PORT, PUPITRE_PROCESS_<ID>_URL	le port et l’adresse de chaque processus du projet
PUPITRE_PROCESS, PUPITRE_PROCESS_DIR	l’identifiant et le dossier du processus
PUPITRE_HOST, PUPITRE_PORT	où le serveur de développement doit écouter
PUPITRE_URL	son adresse publique si elle existe, locale sinon
PUPITRE_LOCAL_URL, PUPITRE_PUBLIC_URL	chacune des deux ; la publique est absente tant que rien n’est publié
PUPITRE_ROUTE_<LABEL>_PORT, PUPITRE_ROUTE_<LABEL>_URL	le port et l’adresse de chaque route du processus

<ID> et <LABEL> passent en majuscules, tiret changé en souligné : le processus api-v2 donne PUPITRE_PROCESS_API_V2_URL. Un client écrit par exemple vite --host $PUPITRE_HOST --port $PUPITRE_PORT, ou pointe vers son API avec PUPITRE_PROCESS_API_URL.

Un processus démarré par l’app reçoit toutes ces variables à son démarrage et les garde : quand elles changent, l’app le signale sur le processus, et un redémarrage applique les nouvelles. Un terminal les reçoit pour le dossier où il se trouve, à chaque invite. PORT et HOST ne sont jamais posés, pour que le .env.local de votre dépôt garde la main ; aucun secret ne passe par là.

Exposition

Par défaut un projet écoute en local et l’app l’atteint par la session SSH qu’elle tient déjà. C’est un état, pas un module : ne cochez aucune exposition et rien n’est publié. Avec exposure.cloudflare installé, vous pouvez donner à un projet une route sur votre domaine — un tunnel pour la machine, une route par projet, DNS et certificat gérés ; exposure.caddy fait de même pour un domaine hors Cloudflare.

Une adresse publiée ne s’ouvre qu’avec une clé d’accès : le projet est protégé dès qu’il est déclaré, et un processus peut rester public pour recevoir des webhooks. L’app ajoute la clé de cet ordinateur à chaque adresse qu’elle ouvre. Voir l’accès aux adresses. Un script du serveur qui appelle son propre projet passe par PUPITRE_LOCAL_URL : PUPITRE_PUBLIC_URL lui demande une clé comme à n’importe quel client.