Mettre en ligne une appli Ruby on Rails et sa base PostgreSQL depuis votre agent IA, par MCP

Prérequis

• Une appli Ruby on Rails 7.1 ou plus récente, avec son Gemfile.lock.
• Un agent IA qui travaille dans un terminal : Claude Code, Codex, Cursor ou Gemini CLI.

Étape 1 : Donnez ces instructions à votre agent

Ouvrez votre agent dans le dossier de votre appli, et collez-lui ces instructions :

Connecte-toi à while avec mon compte (while.sh/agents), puis mets mon appli en ligne.

Sans compte, votre agent met votre appli en ligne à l’essai, en une demande. Pour la garder, ouvrez le lien qu’il vous donne et créez votre compte.

Avec votre compte, votre agent ajoute lui-même le serveur MCP de while. S’il vous le demande, relancez-le. Au premier appel à while, une page s’ouvre dans votre navigateur. Dans Claude Code, si elle ne s’ouvre pas, tapez /mcp, choisissez while, puis Authenticate. Sur cette page, choisissez votre appli, ou « Une nouvelle appli », puis cliquez sur Autoriser.

Étape 2 : Ouvrez votre appli

Votre agent vous donne l’adresse de votre appli, par exemple https://mon-appli.while.cloud, en HTTPS.

Ce que fait votre agent

Il écrit while.yaml à la racine de votre appli :

apiVersion: while/v1
project: mon-appli
services:
  - name: web
    port: 8080
    health:
      path: /up
    resources:
      memory: 512Mi
databases:
  - name: main

Rails est reconnu à son Gemfile, et votre agent reçoit un Dockerfile prêt à construire : plusieurs étages, les fichiers statiques précompilés, un utilisateur sans droits d’administration. Votre agent l’ajoute à votre appli. Si elle a déjà le Dockerfile de Rails, il l’adapte, en commençant par le port.

Au démarrage, bin/rails db:prepare crée la base ou applique les migrations², puis Rails sert vos pages. La route /up de Rails dit à while que votre appli est prête¹. Votre agent génère aussi la clé SECRET_KEY_BASE et la range dans le coffre de while. Avec Rails 8, il branche les bases de Solid Cache, Solid Queue et Solid Cable sur la même base PostgreSQL.

Régler Rails derrière PgBouncer

DATABASE_URL passe par PgBouncer en mode transaction. Votre agent coupe les verrous consultatifs des migrations, que PgBouncer ne garde pas d’une transaction à l’autre :

production:
  primary:
    url: <%= ENV["DATABASE_URL"] %>
    advisory_locks: false

Ajouter un worker Sidekiq

Votre agent déclare un worker, avec la même image et la commande bundle exec sidekiq, et un cache compatible Redis pour sa file d’attente, branché avec son mot de passe. Il le déclare avec durable: true : les tâches en attente survivent à un redémarrage, et aucune n’est évincée quand la mémoire est pleine.

Interroger votre base depuis votre agent

Votre agent lit votre base en SQL par le serveur MCP de while, avec vos droits sur les données, sans pouvoir y écrire.

Sauvegarder avant une migration

Votre agent lance une sauvegarde, aussitôt suivie d’un essai : une base jetable en naît, et ses tables sont relues. Chaque base est aussi sauvegardée tous les jours.

Réserver votre appli à vos collègues

Votre agent ajoute deux lignes au service :

    access: internal
    email_domains: [acme.fr]

Une fois votre Google Workspace ou Microsoft 365 relié à while, avec l’offre Pro, vos collègues l’ouvrent avec leur compte habituel, et votre code reçoit leur nom et leur adresse électronique, sans page de connexion à écrire.

Passer sur votre propre domaine

Votre agent déclare le domaine, vous ajoutez les enregistrements DNS qu’il vous donne, et le certificat HTTPS suit.

Corriger une faille dans vos dépendances

Les dépendances de votre appli sont comparées aux failles connues à chaque mise en ligne, puis chaque jour. Votre agent est prévenu d’une faille grave, et met à jour le paquet en cause.

Revenir à la version d’avant

Dans les 30 minutes qui suivent une mise en ligne, la version d’avant revient en une seconde. Ensuite, en quelques secondes. Une fois la version d’avant revenue, votre agent lit ce qui a cassé dans les journaux de while, corrige et remet en ligne.

Dans la doc : Bases PostgreSQL, Cache Valkey (Redis), Accès interne, Domaine personnalisé, Versions et retour arrière et Failles des dépendances.

Prochaines étapes

• Quitter Heroku pour while
• Comparer les alternatives à Heroku
• Mettre en ligne un conteneur Docker