Projets

Qu'est-ce qu'un projet ?

Un projet rassemble les conteneurs d'une application (front, back, base de données, services annexes) dans ses propres réseaux isolés, avec son quota dédié. Il appartient à une seule organisation.

La page détail d'un projet s'organise en neuf onglets : Conteneurs, Topologie, Déploiement, Dépôts utilisés, Logs, Secrets, Sauvegardes, Sécurité et Groupes réseau. Chacun est décrit plus bas, à l'exception de Sécurité, qui a sa propre page : vous y trouvez aussi le graphique d'historique des vulnérabilités.

Les cartes repliables de l'interface (sections de ressources de la topologie, sauvegardes, sécurité, mode de déploiement, secrets) retiennent leur état ouvert ou fermé dans votre navigateur : vous les retrouvez comme vous les avez laissées à la visite suivante.

La liste des projets

La page Projets liste tous les projets de l'organisation active. Chaque ligne porte une icône, le nom et l'identifiant, le nombre de conteneurs utilisés (rapporté au quota), la date de création et des actions (ouvrir, renommer, supprimer). Un compteur en haut indique votre usage par rapport au plan.

Chaque ligne affiche aussi une barre de santé sur 7 jours, même langage visuel que le tableau de bord : une cellule colorée par jour de la semaine courante, résumant le pire état de conteneur observé ce jour-là. Survolez une cellule pour voir la date, le statut et le nombre de conteneurs en bonne santé rapporté au total. Cliquez une cellule pour ouvrir l'historique détaillé de ce jour, limité à ce projet.

Un projet self-hosted porte, à côté de son nom, un tag avec le nom du serveur qui l'héberge : on repère d'un coup d'œil où chaque projet tourne, sans ouvrir sa page.

Créer un projet

Cliquez sur Créer un projet : une fenêtre vous propose trois façons de démarrer. Choisissez Frameworks pour déployer une application depuis son dépôt, puis donnez un nom au projet, l'identifiant en est dérivé et figé à la création. Selon votre cible de déploiement, choisissez l'agent (serveur) qui hébergera le projet. Confirmez pour créer le projet vide, prêt à recevoir des conteneurs.

Le nombre de projets et de conteneurs par projet dépend de votre plan. Quand le quota de projets est atteint, la fenêtre Créer un projet s'ouvre toujours, mais ses trois options sont désactivées : elle rappelle votre usage et propose de passer à un plan supérieur.

Pour reprendre une application déjà en ligne chez un autre hébergeur, choisissez Migrer depuis un autre hébergeur dans cette même fenêtre : l'assistant crée le projet pour vous, en bêta. Voir Migrer vers Pierrr.

Créer un conteneur

Dans un projet, le bouton dédié ouvre la création d'un conteneur. Vous fournissez un nom, dont l'identifiant est dérivé, puis :

• Le type. Un conteneur web est joignable en HTTP et reçoit un sous-domaine ; un conteneur worker, pour une file de messages ou une tâche planifiée, n'expose aucun port et n'est pas sondé en HTTP. Choisissez-le à la création, il ne se change pas ensuite.
• Le dépôt chez votre fournisseur de code, la branche à surveiller et le dossier du code dans le dépôt, avec un explorateur pour le retrouver.
• Le framework. Si votre Dockerfile porte une ligne LABEL framework, Pierrr le déduit tout seul et verrouille le choix ; sinon vous le sélectionnez, à titre d'information si un Dockerfile existe, ou pour choisir le modèle que Pierrr générera s'il n'y en a pas.
• Un interrupteur « Monorepo : construire depuis la racine du dépôt », quand le Dockerfile vit dans un sous-dossier mais que le build a besoin de voir tout le dépôt.

Onglet Conteneurs

L'onglet Conteneurs présente chaque conteneur du projet sous forme de carte : logo du framework détecté, nom et identifiant, et état en direct. Vous pouvez :

• Lire l'état de santé de chaque conteneur, Sain, En ligne, Dégradé ou Hors-ligne, avec un badge coloré. Un badge de vulnérabilités par sévérité apparaît quand une analyse existe ; un clic ouvre l'onglet Sécurité.
• Démarrer un conteneur arrêté, individuellement ou tous d'un coup via Démarrer tout.
• Arrêter un ou tous les conteneurs pour mettre le trafic en pause.
• Redémarrer un conteneur, utile après une modification de variables d'environnement ou la rotation d'un secret.
• Déployer un conteneur avec le bouton éclair de sa carte : un clic construit et déploie la dernière version de la branche suivie, et le chevron voisin permet de choisir un autre commit.
• Créer un conteneur via le bouton dédié (bloqué par un dialogue d'upgrade si le quota du projet est atteint).
• Ajuster le nombre d'instances d'un conteneur avec le stepper +/- à côté de « Nb d'instances », directement sur la carte.

Actions au niveau du projet

L'en-tête du projet a un menu Actions du projet avec Tout démarrer, Tout arrêter et Tout redémarrer, plus le bouton Créer. Une action sans objet est grisée avec la raison. Le mode de déploiement (l'agent ciblé et la façon dont les déploiements sont déclenchés) se règle dans l'onglet Déploiement.

Menu Plus d'actions d'un conteneur

Le menu Plus d'actions de chaque carte donne accès à Voir le Dockerfile (celui du dépôt lié, ou le modèle de Pierrr, avec un bouton pour le copier), à Ressources, à Renommer et à Supprimer. Renommer recrée le conteneur : une brève interruption a lieu et son sous-domaine Pierrr change, mais vos domaines personnalisés et vos données sont conservés. Supprimer demande de saisir le nom du conteneur et est irréversible.

Actions verrouillées et projets en veille

Une action que votre rôle ne permet pas n'est jamais masquée : elle reste visible, grisée, avec une info-bulle qui en donne la raison. C'est le cas du démarrage et de l'arrêt, des ressources, des secrets, de l'import de données, des sauvegardes, des analyses et de la création de conteneur.

Sur le plan Free, les projets dorment de 0h à 8h (UTC) et sont arrêtés après 30 jours sans activité. Une bannière l'indique en haut du projet avec un bouton Rallumer, et les actions de démarrage sont grisées avec la raison, par exemple « Plan gratuit : projet en veille jusqu'à 8h (UTC) ».

Faire évoluer le nombre d'instances

Chaque carte de conteneur affiche un stepper « Nb d'instances » permettant d'augmenter ou de réduire le nombre d'instances du conteneur sans repasser par un déploiement. Tant que le nombre d'instances actives n'a pas rejoint la cible, un indicateur du type « 2/3 actives » reste visible sur la carte.

Le nombre maximal d'instances par conteneur dépend de votre plan : 1 en Free, 2 en Starter, 4 en Pro et 8 en Business, avec un plafond absolu de 50 instances quel que soit le plan. Au-delà du quota du plan, le stepper propose un dialogue d'upgrade au lieu d'augmenter le nombre d'instances. Une instance de plus est aussi refusée quand le budget de ressources du projet est épuisé.

Limites processeur et mémoire

Chaque conteneur expose ses limites de ressources. Deux valeurs, à ne pas confondre : le plafond, que le conteneur ne peut pas dépasser, et la part garantie, qui lui reste acquise même quand un voisin gourmand tourne sur la même machine. C'est la seconde qui protège votre service, la première qui protège les autres. Elles se règlent depuis le bouton Ressources du menu Plus d'actions de la carte, dans la boîte Limites de ressources : Limite CPU en millicœurs (1000 = 1 vCPU), Limite mémoire en Mo, CPU garanti et Mémoire garantie (vide, rien n'est réservé). Tout le monde peut consulter ces valeurs, la modification est verrouillée avec sa raison pour un rôle sans droit.

Ce que vous pouvez demander pour un conteneur dépend de ce qui reste dans le budget de ressources de son projet, décrit ci-dessous.

Isolation renforcée

Le menu de chaque conteneur propose l'isolation renforcée : l'application tourne alors dans un environnement d'exécution isolé du serveur, qui ajoute une barrière entre son code et la machine. Elle est utile pour du code que vous ne maîtrisez pas entièrement, une dépendance tierce ou un outil que vous n'avez pas écrit. Activer ou retirer l'option recrée le conteneur.

Elle a un coût, mesuré sur nos serveurs de test : environ 50 à 65 Mo de mémoire en plus par conteneur, comptés dans la limite de l'application, un démarrage deux à quatre fois plus lent, et une capacité de réponse divisée par 2 à 5 selon l'application. Vérifiez que la limite mémoire de l'application laisse cette marge avant de l'activer.

Elle est réservée aux applications web : une base de données y perdrait l'essentiel de ses performances, et l'option lui reste verrouillée. Sur votre propre serveur, elle apparaît verrouillée, avec la raison, tant que le serveur ne propose pas cet environnement ou que son agent doit être mis à jour. L'option reste visible pour tous les rôles ; seuls ceux qui peuvent modifier le projet la changent.

Budget de ressources du projet

Un plan ne fixe pas un plafond par app mais un budget par projet, que vous répartissez librement entre les apps du projet : 1 vCPU et 1 Go de mémoire sur Free, 2 vCPU et 2 Go sur Starter, 3 vCPU et 4 Go sur Pro, 4 vCPU et 8 Go sur Business.

Le budget se compte en additionnant, pour chaque app, sa limite multipliée par son nombre d'instances. Une app arrêtée compte quand même pour une instance : la redémarrer ne dépend donc jamais du budget. Les bases de données et les services gérés ne comptent pas.

La carte Budget de ressources du projet montre deux jauges, CPU et mémoire engagés, et la répartition par app. Créer une app, relever une limite ou ajouter une instance qui dépasserait le budget est refusé avant d'avoir le moindre effet ; baisser une limite passe toujours. Le bouton Répartir équitablement donne à chaque instance la même part du budget, sur 90 % de celui-ci : les 10 % restants ne sont jamais distribués, pour garder de la marge, après un aperçu à confirmer.

Les projets qui tournent sur votre propre serveur, avec Pierrr Agent, suivent le même budget.

Si un projet se retrouve au-dessus de son budget, rien n'est arrêté tout de suite : vous avez 7 jours, annoncés par un e-mail puis rappelés la veille. Passé ce délai, seules les apps en surplus sont arrêtées, les plus anciennes continuent de tourner, et rien n'est supprimé.

Le budget ne limite pas seulement ce que vous réservez : Pierrr surveille aussi ce que les apps d'un projet consomment réellement, mesuré chaque minute.

• Dès que les apps du projet consomment plus que son budget, une bannière avec un compte à rebours apparaît en haut de toutes les pages du tableau de bord, et un badge d'alerte signale le projet dans la barre latérale, dans la liste des projets, sur son onglet Topologie et sur la carte Budget de ressources. Au bout de 10 minutes d'affilée au-dessus du budget, les propriétaires et les mainteneurs reçoivent un e-mail et une notification, et le compte à rebours passe à une heure avant l'arrêt.
• Si la consommation dépasse toujours le budget au bout de cette heure, les apps du projet sont arrêtées. Les bases de données, les caches et les fichiers stockés continuent de tourner, rien n'est supprimé, et les visiteurs du site voient une page « temporairement indisponible ».
• Repasser sous le budget à n'importe quel moment avant l'arrêt annule tout.
• Un projet arrêté se rallume depuis la carte Budget de ressources, une fois par période glissante de 24 heures. S'il dépasse à nouveau dans ces 24 heures, sa relance passe par le support, avec le délai de réponse de votre plan. Le rallumage n'est pas décompté si vous avez baissé les limites du projet, ou amélioré votre plan, pour qu'elles tiennent dans le budget.

Les projets qui tournent sur votre propre serveur ne sont pas concernés par cette surveillance. En pratique, elle ne se déclenche que lorsque les limites réservées d'un projet dépassent son budget, par exemple quand un changement de plan ou de budget le laisse au-dessus, le temps qu'il y revienne : tant qu'elles tiennent dans le budget, aucune app ne peut consommer plus que sa propre limite.

Le chemin de santé, /health par défaut

Pierrr impose son propre healthcheck à chaque conteneur : une requête GET sur http://127.0.0.1:<PORT>/health par défaut, indépendamment de tout HEALTHCHECK déclaré dans votre Dockerfile (qui est ignoré : le healthcheck compose de Pierrr prend toujours le dessus). Le chemin se règle par application, voir les réglages de build dans l'onglet Dépôts. Votre app doit donc répondre 200 sur ce chemin, sans le préfixe global de votre framework s'il en a un (ex. NestJS avec setGlobalPrefix('api') : excluez explicitement la route health du préfixe). Sans ça, le conteneur ne passera jamais healthy et chaque déploiement échouera après 90 secondes, même si l'app démarre et fonctionne normalement.

Répondre 200 ne suffit pas à rendre le signal utile. Faites répondre 200 seulement quand votre service peut réellement servir : base joignable ET schéma en place, dépendances indispensables prêtes. Une route qui renvoie 200 dès que le processus tourne indique un processus vivant, pas un service qui fonctionne, et elle ne pourra jamais signaler une panne. Un cas vécu : un `/health` qui vérifiait une extension Postgres installée par Pierrr avant tout code client répondait 200 alors que la base n'avait aucune table.

// NestJS : exclure /health du préfixe global
app.setGlobalPrefix('api/v1', { exclude: ['health'] });

• Aucune configuration côté Pierrr : la route /health doit simplement exister et répondre 200 sur le port de votre app. Un HEALTHCHECK dans votre Dockerfile n'est pas nécessaire (il est ignoré), inutile de le maintenir en double.
• Pendant un déploiement, Pierrr attend que la nouvelle instance passe healthy sur /health (jusqu'à 90 secondes) avant de basculer le trafic ; si elle n'y arrive pas, l'ancienne instance reste en place et le déploiement est annulé.
• L'état healthy/unhealthy renvoyé par Docker alimente le compteur de santé agrégé du serveur et les notifications de conteneur en mauvaise santé, en plus du simple état d'exécution.

/health doit rester accessible sans authentification et sans préfixe, sur le même port que le reste de votre app.

Dockerfiles prédéfinis et préflight

Pierrr embarque un Dockerfile prédéfini pour 34 frameworks : Next.js, NestJS, Express, Fastify, Bun, React, Vue, Svelte, Astro, Remix, Nuxt, Node, BullMQ, sites statiques, FastAPI, Flask, Django, Python, Go, Rust, Deno, Ruby, Rails, PHP, Laravel, Spring, WordPress, PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, Kafka et Traefik. Dans le cas courant, vous n'avez donc rien à écrire : vous choisissez le framework à la création de l'application, et Pierrr sait la construire, la démarrer et la surveiller. Chacun de ces modèles est éprouvé contre une application d'exemple qui se construit, démarre et répond.

Quand votre dépôt contient un Dockerfile, c'est lui qui l'emporte : Pierrr l'utilise tel quel et ne le remplace jamais par un modèle. Avant chaque build, Pierrr vérifie votre Dockerfile et quelques fichiers du projet pour attraper les erreurs les plus courantes. Une erreur bloquante arrête le build avec un message clair ; les avertissements n'arrêtent pas le build et apparaissent dans les logs de déploiement, préfixés par préflight.

Avec un Dockerfile prédéfini, les commandes d'installation, de construction et de démarrage restent les vôtres : elles se modifient dans les réglages de l'application, avec le dossier de sortie et le chemin de santé. Vos valeurs remplacent celles du modèle, sans avoir à écrire une ligne de Dockerfile.

Les variables du coffre sont injectées à l'EXÉCUTION du conteneur, jamais comme arguments de build : `docker build` ne les voit pas. Cela compte pour les frameworks qui figent leurs variables publiques à la compilation (`NEXT_PUBLIC_*` avec Next.js, `VITE_*` avec Vite) : la valeur du coffre n'atteindra pas votre bundle, qui gardera la valeur de repli codée dans votre source. Rien n'échoue au déploiement, et le défaut ne se voit qu'en regardant les appels réseau du navigateur. Lisez ces valeurs côté serveur au démarrage et passez-les à vos pages, plutôt que de les figer au build.

• LABEL avant le premier FROM (bloquant) : Docker refuse de builder un Dockerfile dont une ligne LABEL précède le premier FROM. Placez toujours votre ligne LABEL framework après un FROM. Ce cas est aussi signalé en rouge dès la sélection du dépôt, avant même le build.
• Prisma sans openssl ni schéma (avertissement) : le postinstall prisma generate a besoin du schéma et d'openssl au moment du build. Sur une base alpine, ajoutez RUN apk add --no-cache openssl et copiez COPY prisma ./prisma avant d'installer les dépendances.
• reactCompiler sans @swc/helpers (avertissement) : si reactCompiler est activé dans next.config, ajoutez @swc/helpers à vos dependencies, sinon l'build standalone de Next ne l'embarque pas et le conteneur plante au démarrage.
• Application sans serveur web (bloquant) : un modèle de traitement de file n'écoute sur aucun port et n'a donc aucune réponse de santé à donner. Déclarez l'application en type « Worker » dans ses réglages. Sinon le déploiement est refusé aussitôt, avec le réglage à changer, au lieu d'attendre longuement une réponse qui n'arrivera jamais.

Ces vérifications vous évitent un build qui échoue sans message ou un conteneur qui plante au démarrage. Les avertissements restent des conseils : vous gardez la main sur votre Dockerfile.

Valeurs dont votre framework a besoin au build

Certains frameworks résolvent des valeurs pendant la compilation et non à l'exécution. Le cas le plus courant est le `metadataBase` de Next.js, dont dépendent les URL canoniques et les balises Open Graph : si vos pages sont prérendues statiquement, la valeur est figée au moment du `docker build`, c'est-à-dire avant que Pierrr n'injecte quoi que ce soit. Les pages sortent alors avec `http://localhost:3000` en canonique, ce qu'un robot d'indexation ou un aperçu de partage utilisera vraiment.

Pierrr ne passe pas les variables du coffre en arguments de build, et ne le fera pas : un `ARG` reste lisible dans l'historique de l'image (`docker history`), donc le mécanisme pousse naturellement à y mettre des valeurs qui n'ont rien à y faire. Un `ARG` déclaré mais non renseigné produit par ailleurs une chaîne vide, pas une variable absente, ce qui transforme un oubli en `new URL('')` au lieu d'une erreur explicite.

La solution tient en deux règles. D'abord, lisez la variable paresseusement dans une fonction, jamais dans un `const` au niveau du module : un `const` est évalué une seule fois et peut être figé dans le bundle, alors qu'un appel de fonction relit `process.env` dans le conteneur en marche.

// env.ts : lu à chaque appel, côté serveur, dans le conteneur en marche.
export function getPublicOrigin(): URL {
  return new URL(process.env.PUBLIC_WEB_ORIGIN ?? 'http://localhost:3000');
}

// app/layout.tsx
export async function generateMetadata(): Promise<Metadata> {
  return { metadataBase: getPublicOrigin() };
}

Ensuite, assurez-vous que la métadonnée est bien évaluée à la requête. Une page prérendue statiquement exécute `generateMetadata` au build, où la variable n'existe pas encore. La régénération incrémentale ne suffit pas tout à fait : la première visite après un déploiement reçoit encore la sortie du build. Pour que ce soit juste dès la première requête, dérivez l'origine de l'en-tête `Host` plutôt que d'une variable, ce qui rend la page dynamique et supprime le besoin de configurer quoi que ce soit :

import { headers } from 'next/headers';

export async function generateMetadata(): Promise<Metadata> {
  const h = await headers();
  const host = h.get('x-forwarded-host') ?? h.get('host');
  return { metadataBase: new URL(`https://${host}`) };
}

Pour une valeur dont un composant client a besoin, le principe est le même : lisez-la dans un composant serveur et passez-la en propriété. Le composant client la reçoit à l'exécution, sans jamais dépendre d'une variable figée à la compilation.

Onglet Topologie

La Topologie affiche conteneurs, base de données managée, stockage objet et, une fois lié, votre add-on Redis sous forme de graphe hiérarchique organisé par niveau : proxy, frontend, backend, cache, base de données. Les réseaux ne sont pas des nœuds à part : ils apparaissent comme des arêtes entre les conteneurs qui les partagent, cliquez une arête pour voir le détail des liaisons réseau sous-jacentes (nom, alias). Sélectionnez un nœud pour voir ses détails (points de montage, réseaux attachés, alias, isolation, badge de vulnérabilités) et agir dessus : démarrer, arrêter ou redémarrer un conteneur, monter ou démonter un volume, délier une instance Redis (le Postgres managé se délie depuis l'onglet Secrets, voir plus bas). Le nœud stockage objet montre son bucket et ses identifiants, avec un lien Lier le stockage tant qu'il n'est pas relié. Le nœud base de données est étiqueté partagée (plan Free) ou dédiée (plan payant), une distinction pilotée par le plan aujourd'hui, pas encore une instance physiquement séparée. Quand le projet n'a encore aucun conteneur, un état vide invite à en créer.

Options du graphe

Le bouton Rafraîchir relit la santé des nœuds. Le menu Options d'affichage masque les volumes, les réseaux ou les conteneurs, et la mini-carte s'affiche ou se masque. Enregistrer la position conserve la disposition que vous avez donnée aux nœuds, Réinitialiser la position revient à la disposition automatique. La légende rappelle les quatre états Sain, En ligne, Dégradé et Hors-ligne.

Consommation du projet

Sous le graphe, deux cartes repliables suivent la charge. Ressources du projet montre des jauges CPU et mémoire par rapport à la somme des ressources allouées, et des courbes de la dernière heure avec les valeurs Actuel, Moyenne et Pic. Détail par application donne la même lecture app par app, avec la répartition actuelle. Repliées, elles gardent un aperçu : la charge actuelle, ou le nombre d'applications et la plus gourmande. Sans mesures, un état vide indique « Pas encore de mesures ».

Add-ons Volume et Redis

Un volume et une instance Redis s'achètent en add-ons depuis Facturation, puis Add-ons. Un volume s'achète par sa taille en Go (0,50 € par Go et par mois), sans nom ni projet : il apparaît ensuite sur les pages de vos projets, où vous le liez à un projet et lui donnez son nom. Ce lien est définitif, un volume ne se déplace pas vers un autre projet. Un volume lié démarre non monté : ouvrez son nœud dans la Topologie pour l'attacher à un conteneur et un chemin de montage. Une instance Redis achetée n'a pas de nœud tant qu'elle n'est pas liée : liez-la à un projet depuis le panneau Redis au-dessus de la Topologie, puis déliez-la depuis son nœud dans la Topologie une fois connectée.

Connecter une ressource à un conteneur

Une ressource managée n'atteint un conteneur que si vous l'y connectez explicitement : acheter un stockage objet ou lier une base ne suffit pas, et rien n'est diffusé à l'ensemble du projet par défaut. La commande se trouve sur le nœud de la RESSOURCE, pas sur celui du conteneur : ouvrez le nœud base de données, cache ou stockage dans la Topologie, et cochez les conteneurs qui doivent le recevoir. Les variables correspondantes (DATABASE_*, CACHE_*, STORAGE_*) sont injectées au déploiement suivant, et un conteneur non connecté démarrera sans elles. Depuis un conteneur, la ligne Ressources connectées indique ce à quoi il est rattaché, ou signale qu'il ne l'est à rien.

Onglet Déploiements

L'historique liste chaque déploiement du projet, du plus récent au plus ancien (paginé). Pour chaque ligne :

• Les quatre étapes du pipeline, build (construction de l'image), push (envoi vers le registre), load (récupération de l'image) et start (création + démarrage du conteneur), chacune avec son icône d'état.
• Un badge de statut mono (Réussi, Échec, En cours, En attente, Annulé).
• Le conteneur (logo + nom + identifiant), la branche et le commit (cliquables vers votre dépôt chez votre fournisseur de code, votre propre instance comprise), l'heure de démarrage et la durée.
• Le nombre de tentatives quand un déploiement a été relancé. Une étape peut aussi être Ignorée ou Réutilisée. Un déploiement dont le conteneur a été supprimé affiche Supprimé, avec la mention que les détails sont indisponibles.

Déployer un commit précis

Le bouton de déploiement présent sur la carte de chaque conteneur est scindé en deux. L'action principale n'a pas changé : un clic construit et déploie la dernière version de la branche suivie, sans étape ni requête supplémentaire.

Le chevron qui lui est accolé ouvre une fenêtre listant les commits récents de cette branche. Une barre de recherche filtre la liste par message, par auteur ou par empreinte, sous sa forme courte comme complète. Chaque ligne affiche le message du commit, son empreinte courte et son auteur.

Sélectionner une ligne lance immédiatement le déploiement de cette version, à la place de la dernière. C'est le moyen de revenir à une version connue comme bonne sans toucher à votre dépôt, ou de livrer un correctif déjà validé alors que la branche a continué d'avancer.

Le commit choisi est enregistré sur le déploiement : c'est son empreinte que vous retrouvez dans l'historique, et c'est bien ce code qui est mis en ligne. Si le conteneur tourne déjà et que la dernière image construite correspond au commit choisi, elle est réutilisée plutôt que reconstruite.

La liste est chargée à l'ouverture de la fenêtre, jamais avant, et couvre les trente derniers commits de la branche suivie. Si elle ne peut pas être récupérée, par exemple quand aucun dépôt n'est lié au conteneur, la fenêtre l'indique et le déploiement de la dernière version reste disponible.

Où tourne le projet

L'onglet Déploiement porte le mode de déploiement du projet, dans un accordéon ouvert par défaut dont l'état est mémorisé : sur l'infrastructure de Pierrr, le réglage par défaut, ou en self-hosted sur l'un de vos serveurs, que vous choisissez alors dans la liste des agents en ligne.

Sur votre serveur, la base de données du projet est créée sur la machine par l'agent, jamais chez Pierrr : la console l'indique « Base sur votre serveur », sans jauge de quota. Le cache et les volumes s'y ajoutent depuis le projet, sans achat. Un tel projet ne peut pas changer de serveur tant qu'il a sa base, sauf vers un agent réinstallé sur la même machine. Le panneau et l'import de base de données passent par l'agent, sur le serveur même. Ses analyses de sécurité tournent sur le serveur même, et seul leur rapport remonte à Pierrr. Un site WordPress se crée directement sur votre serveur, avec sa base sur la machine ; un site créé sur l'hébergement Pierrr garde sa base chez Pierrr et ne peut pas y passer.

Sur un serveur à vous, l'URL propre d'une application affiche un badge d'échec quand son accès public n'a pas pu être synchronisé, par exemple parce que les ports 80 et 443 sont occupés par un autre programme : le lien seul ne laissait pas deviner que l'adresse n'était pas joignable.

Migrer la base vers votre serveur

Un projet dont la base est gérée par Pierrr peut passer sur l'un de vos serveurs avec ses données. Dans l'onglet Déploiement, choisissez « Votre serveur » puis le serveur cible : le bouton « Migrer la base vers ce serveur » remplace l'enregistrement simple du mode. Il demande un serveur en agent 0.78.0-beta ou plus récent, dont l'installation est finalisée et dont la base de données locale est en bonne santé ; sinon le bouton reste verrouillé, avec la raison.

Une boîte de dialogue résume ce qui va se passer avant de lancer la copie :

• Le projet est arrêté pendant la copie, de quelques secondes à quelques minutes selon la taille de la base.
• Vos applications ne sont pas redéployées automatiquement : une fois la migration terminée, redéployez-les sur le nouveau serveur.
• La base d'origine est conservée 7 jours, puis supprimée automatiquement. Vous pouvez la supprimer plus tôt.
• Si la copie échoue, rien ne change : le projet reste sur Pierrr avec sa base et redémarre.

La carte « Migration de la base en cours » suit les étapes : arrêt du projet, export de la base, import sur le serveur, bascule du projet, nettoyage. Elle continue même si vous quittez la page, et la sélection du mode est verrouillée le temps de la copie.

À la fin, la carte « Base migrée vers votre serveur » rappelle de redéployer vos applications et affiche la date de suppression de la base d'origine. « Supprimer maintenant » la supprime plus tôt, après saisie de l'identifiant du projet : c'est définitif. En cas d'échec, la carte « La migration de la base a échoué » en donne la raison et confirme que le projet est resté intact sur Pierrr.

Mode accéléré

Par défaut, enchaîner plusieurs pushes fait patienter chaque déploiement derrière le précédent : la version que vous vouliez réellement mettre en ligne part en dernier, après des constructions devenues inutiles. L'interrupteur Mode accéléré, dans l'accordéon Mode de déploiement, change cela : un nouveau déploiement annule celui qui tourne encore pour ce conteneur et prend sa place.

L'effet reste borné au conteneur concerné : relancer votre conteneur api n'interrompt jamais la construction en cours de votre conteneur web. Le réglage est désactivé par défaut, et un déploiement écarté de cette façon porte son propre motif dans l'historique, à ne pas confondre avec une annulation manuelle.

Annuler, relancer, exporter

• Annuler, tant que le déploiement est en attente ou en cours.
• Relancer, sur un déploiement en échec. La nouvelle tentative repart de l'étape qui a échoué, les étapes déjà réussies sont réutilisées telles quelles.
• Télécharger le journal complet d'une tentative, pour l'analyser hors de la console ou le joindre à une demande d'aide.

Les journaux de build sont conservés un temps qui dépend de votre plan, rappelé sur la page de détail du déploiement.

Détail d'un déploiement

Cliquez une ligne pour ouvrir le détail. L'en-tête montre le statut et les actions : Annuler, Relancer, Redéployer ce commit, Ouvrir le site, Essais et Plus d'actions. La carte Détails résume le statut, l'étape en échec, l'origine (automatique ou lancé par un membre), la durée, le conteneur actuel, l'intention (Build seul ou Build et mise en ligne), les domaines, la source et l'empreinte du commit, copiable. Des raccourcis mènent aux logs d'exécution, à l'historique de santé, aux ressources, à la sécurité et au dépôt.

Comprendre un échec

Un déploiement en échec affiche son motif en clair (annulé, remplacé par un plus récent, projet en veille, serveur muet, mémoire insuffisante, contrôle de santé non satisfait sur le chemin, échec du build, de la publication, du chargement ou du démarrage), avec des actions d'aide : Ajuster les ressources, Logs d'exécution, Régler le chemin de santé.

Le reste de la page est organisé en sections repliables : Réglages du build (avec des recommandations), Logs du build (ouvert par défaut, filtre par étape, recherche et Télécharger, durée de conservation selon le plan), Résumé du déploiement (étape, statut, durée, début et fin par essai), Vérifications (contrôle de santé au démarrage) et Domaines personnalisés. C'est là que vous diagnostiquez un build cassé ou un conteneur qui ne démarre pas.

Onglet Dépôts

L'onglet Dépôts liste les dépôts de votre fournisseur de code liés aux conteneurs du projet, avec la branche surveillée et le chemin du Dockerfile. C'est le lien entre votre code et chaque conteneur déployé depuis un push. Le menu de chaque ligne permet de Modifier la branche, de Modifier les chemins de build (Dockerfile, modèle .env, monorepo) et de Modifier les commandes de build.

Chaque dépôt lié affiche un interrupteur Déploiement auto, activé par défaut. Tant qu'il reste activé, un push sur la branche surveillée déclenche un build et un déploiement pour ce conteneur, quel que soit votre fournisseur de code. Le désactiver n'affecte que ce conteneur : les autres conteneurs du même projet ou du même dépôt continuent de se déployer normalement, et la liaison avec votre fournisseur de code reste en place, elle ne fait simplement plus rien tant que l'interrupteur est éteint.

Cliquez sur Modifier à côté de la branche surveillée pour pointer le conteneur vers une autre, par exemple pour promouvoir une feature branch en production, sans supprimer et recréer le conteneur. Cela change uniquement quels futurs push déclencheront un déploiement : le conteneur actuellement en cours d'exécution n'est pas redéployé pour autant. Déclenchez ensuite un déploiement avec un push sur la nouvelle branche, ou via le bouton Build du conteneur.

Les réglages de build s'éditent par application : commande d'installation, de build et de démarrage, dossier de sortie et chemin de santé.

Onglet Logs

L'onglet Logs affiche les journaux des conteneurs. Choisissez le conteneur dans le sélecteur ; quand le projet n'a aucun conteneur, un état vide le signale.

Par défaut, les logs se rafraîchissent périodiquement, avec un bouton Actualiser. Activez Direct pour les diffuser en temps réel à la place ; les deux modes ne fonctionnent jamais en même temps. La barre propose aussi un sélecteur de fenêtre de temps, la recherche avec un compteur de lignes (x / y) et l'option Tous les conteneurs. Les couleurs des logs sont conservées.

Pour un projet hébergé sur votre serveur, les logs sont lus sur la machine, auprès de l'agent, à l'ouverture de l'onglet : ils ne sont jamais stockés chez Pierrr.

Onglet Secrets

L'onglet Secrets gère un coffre chiffré par projet (variables d'environnement, clés d'API…). Chaque secret peut être injecté dans les conteneurs selon trois modes :

• Bound, un conteneur ne reçoit que les secrets que vous lui avez explicitement liés.
• Detected, un conteneur reçoit les secrets du coffre dont la clé est déclarée dans son `.env.example`.
• All, un conteneur reçoit TOUS les secrets du coffre (portée org + projet), indépendamment du binding ou du `.env.example`.

Le choix du mode est réservé aux plans payants. Sur le plan Free il est figé : tous les conteneurs reçoivent l'intégralité du coffre.

Section « Géré par Pierrr »

Une section en lecture seule liste les variables que Pierrr injecte automatiquement dans vos conteneurs, sans configuration manuelle. Elles gagnent toujours sur le coffre et ne peuvent être ni éditées ni supprimées depuis le coffre tant que la ressource correspondante reste liée. Si vous tentez de créer manuellement un secret portant l'un de ces noms, Pierrr refuse et indique explicitement comment débloquer la variable : délier la ressource concernée.

• Postgres managé (lié par défaut à chaque projet) : `DATABASE_URL`, `DATABASE_HOST`, `DATABASE_PORT`, `DATABASE_NAME`, `DATABASE_USER`, `DATABASE_PASSWORD`. Ces noms sont volontairement génériques plutôt que `PG*` : libpq ne les reconnaît pas automatiquement, donc un conteneur qui héberge son propre Postgres ne voit jamais son outillage détourné vers l'instance managée par accident. Un toggle « Utiliser le Postgres managé Pierrr », juste au-dessus de cette section dans l'onglet Secrets, permet de délier le projet sans détruire la base ni les identifiants. Une fois délié, ces noms se libèrent et vous pouvez les définir vous-même dans le coffre, par exemple pour pointer `DATABASE_URL` vers une base externe. Délier est réservé aux plans payants : sur le plan Free, le toggle ouvre une fenêtre d'upgrade.
• Add-on Redis (une fois lié à ce projet depuis Facturation puis Add-ons) : `CACHE_URL`, `CACHE_HOST`, `CACHE_PORT`, `CACHE_PASSWORD`. Même logique que ci-dessus : `CACHE_*` plutôt que `REDIS_*`, pour que redis-cli ne s'y branche pas tout seul. Déliez-le depuis son nœud dans l'onglet Topologie pour libérer ces noms ; aucune restriction de plan ne s'applique.
• Add-on Stockage objet, compatible S3 (une fois lié au projet, puis chaque conteneur connecté individuellement) : `STORAGE_ENDPOINT`, `STORAGE_PUBLIC_URL`, `STORAGE_REGION`, `STORAGE_BUCKET`, `STORAGE_ACCESS_KEY`, `STORAGE_SECRET_KEY`. `STORAGE_ENDPOINT` est l'adresse interne au réseau du projet ; `STORAGE_PUBLIC_URL` est l'origine que le navigateur atteint, et c'est elle que vos URLs présignées doivent porter, sinon leur signature ne sera pas validée. Le bucket créé d'office porte l'identifiant du projet : c'est un défaut pratique, pas une limite, votre application peut en créer d'autres.
• Extensions Postgres : `pgvector`, `pg_trgm`, `pgcrypto`, `uuid-ossp`, `unaccent`, `citext` et `btree_gin` s'activent projet par projet depuis l'onglet Topologie. Pierrr exécute la création avec les droits nécessaires ; le rôle de votre base reste volontairement restreint, donc une migration qui fait `CREATE EXTENSION IF NOT EXISTS` fonctionne une fois l'extension activée, sans que vous ayez à la modifier.

Prisma

Prisma a besoin d'une seconde variable en plus de `DATABASE_URL` : `DIRECT_URL`, utilisée uniquement pour les migrations. Elle sert normalement à contourner un connection pooler (PgBouncer, Supabase…) placé devant la base, qui ne supporte pas certaines commandes DDL exécutées par `prisma migrate`. La base Postgres managée par Pierrr est déjà une connexion directe, sans pooler devant elle : il suffit donc de faire pointer `DIRECT_URL` vers la même valeur que `DATABASE_URL`.

Dans votre `schema.prisma`, déclarez les deux variables sur le datasource :

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

Puis, dans le point d'entrée de votre conteneur (CMD du Dockerfile ou script de démarrage du `package.json`), exportez `DIRECT_URL` à partir de `DATABASE_URL` avant de lancer les migrations :

export DIRECT_URL="$DATABASE_URL"
npx prisma migrate deploy

Aucune action n'est nécessaire côté Pierrr : `DIRECT_URL` n'est pas une variable gérée, elle vit entièrement dans le code de votre application.

Édition groupée (coller un .env)

Plutôt que d'ajouter vos variables une par une, l'édition groupée vous permet de coller tout un bloc au format .env d'un coup. Pierrr compare votre collage aux variables existantes du projet et applique uniquement les différences.

Pas à pas :

1. Ouvrez votre projet, puis l'onglet Secrets. En haut à droite de la carte, cliquez sur le bouton Édition groupée (à côté de Ajouter une variable).
2. Dans la fenêtre qui s'ouvre, collez votre contenu .env dans la zone de texte : une variable par ligne, au format CLE=valeur. Les valeurs peuvent être entre guillemets.
3. Pour supprimer une variable existante, ajoutez une ligne préfixée par un point d'exclamation, par exemple !OLD_FLAG.
4. Lisez l'aperçu sous la zone de texte : il indique combien de variables seront ajoutées, remplacées et supprimées, et surligne en rouge les lignes invalides (le bouton Appliquer reste désactivé tant qu'une ligne est invalide).
5. Cliquez sur Appliquer. Les variables sont enregistrées (les nouvelles sont masquées par défaut) et la liste se met à jour immédiatement.

Exemple de contenu à coller :

DATABASE_URL=postgres://user:pass@db:5432/app
API_KEY=sk_live_123
# remplace une clé existante, ajoute une nouvelle
NODE_ENV=production
# supprime une variable qui existait
!OLD_FLAG

Règles de fusion appliquées à votre collage :

• Une clé déjà présente est remplacée par la valeur collée.
• Une clé absente est ajoutée (masquée par défaut).
• Une ligne préfixée par ! (ex. !ANCIENNE_CLE) supprime la variable si elle existe.

L'aperçu en direct récapitule, avant d'appliquer, le nombre d'ajouts, de remplacements et de suppressions, et signale les lignes invalides à corriger.

Onglet Sauvegardes

Ouvrez Archiver pour créer ou restaurer une sauvegarde. Deux types sont disponibles :

• Sauvegarde de données, un run unique pour tout le projet : chaque volume de chaque conteneur, plus un dump de la base managée liée. Donnez-lui un nom, sinon un nom est généré automatiquement ; l'historique liste chaque run par ce nom. La restauration écrase l'état courant du conteneur ; elle est destructive et demande une confirmation.
• Export de projet Pierrr, exporte uniquement la structure du projet (conteneurs, liaisons de dépôts, groupes réseau et métadonnées des volumes), sans les données. Valider un export vis-à-vis d'une autre organisation vérifie qu'elle a une installation GitHub App correspondante pour chaque dépôt ; recréer le projet là-bas est une prochaine étape documentée, pas encore livrée.

L'export de projet se crée, se télécharge et se valide vis-à-vis d'une autre organisation. Sa réimportation n'est pas encore disponible : le bouton correspondant est visible mais inactif.

Les sauvegardes de données ne sont pas incluses sur le plan Free : l'onglet propose alors une montée en gamme. Sur les plans payants, la durée de conservation des archives dépend du plan, et les plus anciennes sont purgées automatiquement.

Planifier les sauvegardes

Un accordéon Planification règle une sauvegarde récurrente du projet : quotidienne ou hebdomadaire, avec le jour de la semaine et l'heure de passage en UTC, et une option pour recevoir un email après chaque passage. Les sauvegardes planifiées apparaissent dans le même historique que celles lancées à la main.

Restaurer une sauvegarde réécrit les volumes et la base du projet avec le contenu de l'archive, et redémarre le projet. L'opération est destructrice pour les données actuelles et demande donc une confirmation.

Une sauvegarde réussie se télécharge, pour garder une copie hors de Pierrr.

Un graphique d'historique de la taille suit vos sauvegardes réussies dans le temps. Il indique la taille de la dernière, l'écart avec la précédente et le pic, pour repérer une base qui gonfle. Les sauvegardes en échec ou en cours n'y figurent pas.

Importer mes données (restauration d'un dump SQL)

En haut de l'onglet Sauvegardes, à côté du bouton Sauvegarder, le bouton Importer mes données ouvre une fenêtre qui restaure un dump SQL existant directement dans la base managée du projet, sans passer par SSH ni `psql`.

• Format : fichier `.sql` en texte brut uniquement, 15 Mo maximum. Le format binaire `pg_dump --format=custom` n'est pas accepté.
• Un seul import peut tourner à la fois par projet ; relancez une fois le précédent terminé.
• Tout ou rien : le dump s'exécute en une seule transaction. En cas de conflit avec l'existant (par exemple une table déjà présente), l'import échoue entièrement et rien n'est appliqué, vous pouvez réessayer sans risque.
• Une liste d'historique affiche en direct chaque import (nom du fichier, taille, statut : en attente, en cours, réussi, échoué) avec le message d'erreur visible en cas d'échec.
• Le contenu du fichier envoyé est chiffré au repos et n'est jamais conservé une fois la restauration terminée, qu'elle réussisse ou échoue.

Pour un projet hébergé sur votre serveur, l'agent vérifie le fichier puis le restaure sur la machine, avec les droits du projet et les mêmes règles. Vous pouvez aussi donner une adresse https : votre serveur télécharge alors le fichier lui-même, sans qu'il passe par Pierrr, et seuls son hôte et son nom restent dans l'historique. Il faut l'agent 0.71.0-beta ou plus récent : le bouton est grisé avec la raison sinon.

Onglet Groupes réseau

Regroupez les conteneurs du projet dans des réseaux isolés. Chaque projet démarre avec un groupe protégé internal qui ne peut être ni renommé ni supprimé. Créez des groupes supplémentaires avec Ajouter, puis utilisez Gérer les membres pour choisir quels conteneurs rejoignent chaque groupe. Disponible sur les plans dont la politique réseau est choice ; en Free, les projets restent verrouillés sur le seul groupe internal.

Le menu d'actions d'un projet, le « ... » à côté de Démarrer, Arrêter et Redémarrer, propose Resynchroniser les réseaux : il rattache immédiatement chaque conteneur à sa configuration réseau, sans attendre le prochain déploiement. Utile pour dépanner un conteneur injoignable sur le réseau attendu. Disponible sur toutes les offres.

Chaque groupe réseau se déplie sur un panneau de trafic : débit entrant et sortant, volume reçu et envoyé, CPU et mémoire du groupe, avec un graphe du débit sur la dernière heure. Ces mesures viennent du serveur qui héberge le projet ; tant qu'aucune n'est disponible, le panneau affiche un état vide.

Comme pour les secrets, la création de groupes supplémentaires est réservée aux plans payants : sur le plan Free, le projet reste sur son unique groupe internal.

Ports TCP publiés

Certains protocoles ne se routent pas en HTTP. Une carte Ports TCP publiés, au bas de l'onglet Groupes réseau, expose un port de conteneur directement sur l'adresse publique du serveur. Choisissez le conteneur, le port interne, et éventuellement un port public différent.

Une plage contiguë est possible, pour un service qui en a besoin, comme le mode passif d'un serveur de fichiers.

Deux réserves. Chaque port ouvert est une surface d'exposition de plus : ne publiez que ce dont le service a réellement besoin. Et redéployer un conteneur qui publie un port coupe brièvement le service, un port ne pouvant pas être détenu par l'ancienne et la nouvelle instance en même temps.

Le nombre de ports publiables par conteneur dépend du plan, à partir du plan Starter. Le plan Free n'en publie aucun.

Panneau de base de données

Le menu d'actions d'un projet ouvre, quand l'instance en met un à disposition, un panneau d'administration de la base managée dans un nouvel onglet : de quoi inspecter vos tables et lancer une requête sans installer de client sur votre poste. Vous y arrivez déjà authentifié, et vous n'y voyez que la base de ce projet.

Pour un projet hébergé sur votre serveur, l'agent démarre le panneau sur la machine, à côté de la base, sans ouvrir de port, et la console y accède par sa connexion. Les identifiants de la base restent sur le serveur ; les pages du panneau transitent par Pierrr sans y être conservées. Le panneau se ferme après 15 minutes sans activité. Il faut l'agent 0.71.0-beta ou plus récent : l'action est grisée avec la raison sinon.