Votre appli, construite depuis ses sources et servie en HTTPS. while reconnaît Node.js, Python ou Go, joue vos tests et garde chaque version.

Vous, à votre agent : Mets mon appli en ligne avec while.

Ce que votre agent écrit

Votre agent l’écrit dans while.yaml, à la racine de votre appli :

while.yaml

services:
  - name: web
    title: Lecture des ventes
    port: 3000
    health: { path: /health }
    build:
      args: { VITE_TITRE: Ventes }
      secrets: [NPM_TOKEN]

Ce que reçoit votre appli

Votre appli reçoit ces variables d’environnement à chaque mise en ligne :

Variable	Ce qu’elle contient
`PORT`	Le port sur lequel votre appli écoute, celui de while.yaml.
`HOST`	L’adresse d’écoute, 0.0.0.0.
`WHILE_RELEASE`	L’identifiant de la version en ligne.

Quand vous en servir

Servez-vous-en pour tout ce qui répond à des requêtes HTTP : un site, une API, une appli pour des personnes.

Comment ça marche

while construit votre appli depuis ses sources et la sert en HTTPS. Il reconnaît Node.js, Python ou Go et écrit le Dockerfile, ou prend le vôtre, puis joue vos tests et fige l’image de chaque version.

Ce qu’il faut savoir

Un projet a jusqu’à 10 services. Un service non public (public: false) n’a pas d’adresse sur Internet.

build.args passe à la construction des valeurs qui ne sont pas secrètes (—build-arg), et refuse un nom qui ressemble à un secret (TOKEN, KEY, SECRET, PASSWORD). Les secrets de construction, comme NPM_TOKEN pour un registre npm privé, se nomment dans build.secrets. Leur valeur se pose à part, avec set_env { build: true } (8 caractères au moins), jamais dans while.yaml.

Un secret de construction est monté le temps d’un RUN dans /run/secrets/<NOM>, jamais dans l’image, et masqué au journal. Une construction ne lit jamais les secrets de l’appli, et l’appli ne reçoit jamais ceux de la construction. Chaque environnement a les siens, et une prévisualisation venue d’un fork n’en reçoit aucun. Toute construction de l’environnement les lit, avant même la validation d’une mise en production : donnez un jeton en lecture seule.

Pour un registre npm privé, un .npmrc à la racine du service lit la variable (//npm.acme.fr/:_authToken=${NPM_TOKEN}, ou ${NPM_TOKEN:-} dans .yarnrc.yml), et le Dockerfile généré ne la donne qu’à l’installation. Avec votre propre Dockerfile, écrivez RUN --mount=type=secret,id=NPM_TOKEN NPM_TOKEN=$(cat /run/secrets/NPM_TOKEN) npm ci, et ne copiez jamais /run/secrets/<NOM> dans l’image. Après la construction, while cherche la valeur des secrets dans les dossiers de l’appli (/app, /srv, /opt, /home, /usr/local…) : s’il la trouve, la construction échoue avec le Dockerfile généré, et continue avec un avertissement au journal avec le vôtre.

Une appli Node démarrée directement par node (scripts.start : node server.js) n’a ni npm, ni npx, ni yarn dans son image. Lancez un binaire de dépendance par ./node_modules/.bin/<nom>, par exemple command: [./node_modules/.bin/prisma, migrate, deploy] ; une commande du while.yaml qui appelle npm, npx ou yarn les garde. De même, une appli Python n’a ni pip, ni setuptools, ni wheel dans son image, sauf si une commande du while.yaml appelle pip.

Prix

Ces prix sont les mêmes dans toutes les offres, hors taxes :

Ressource	Prix	Détail
Processeur et mémoire	17 € par vCPU·mois et 8,50 € par Gio·mois	applis à la consommation, caches à la réservation

Les outils MCP de votre agent

Votre agent s’en occupe avec les outils deploy_app, get_app_status et set_env.

Services web