Sources et déploiement

4 façons d'amener du code dans un site Iridflow : starter, git clone, zip upload, MCP push_files.

Comparatif

Starter

Chaque runtime a un starter minimal qui fonctionne. Aucune saisie n'est demandée : Iridflow dépose lui-même le code de base dans le site.

• static : index.html avec landing Iridflow
• node-generic : Express + server.js + package.json
• python-generic : FastAPI + main.py + requirements.txt
• wordpress : install auto, complète via /wp-admin/install.php
• django, rails : projet vide bootstrappé

Ce code se remplace ensuite comme n'importe quel autre, par dépôt Git ou par envoi de fichiers.

Git clone

Iridflow clone ton repo au moment du create_site.

// Payload create_site
{
  "name": "mon-site",
  "runtime": "nextjs",
  "source_git": {
    "url": "https://github.com/mon-org/mon-repo.git",
    "branch": "main",
    "token": "ghp_xxx",             // si privé (PAT)
    "subpath": "apps/web"           // si monorepo
  }
}

Providers supportés : GitHub, GitLab, Bitbucket, Gitea (self-hosted), tout git HTTPS avec PAT.

Format d'auth injecté : https://oauth2:TOKEN@host/... (universel).

Créer un token pour repo privé

Iridflow n'a besoin que de lire le repo (git clone). Ne jamais créer de token avec droits d'écriture ou d'admin : en cas de fuite, l'impact serait minimal (lecture du code seulement).

GitHub

Deux options selon le type de repo :

• Fine-grained personal access token (recommandé, plus étroit) :
  1. Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token
  2. Repository access : Only select repositories + choisis le repo à cloner
  3. Permissions → Repository permissions → Contents : Read-only
  4. (Rien d'autre : ni Metadata write, ni Pull requests, ni Actions)
  5. Expiration : max 1 an
• Classic PAT (si repo dans une org qui n'autorise pas encore fine-grained) : scope repo uniquement (donne read-only en clone HTTPS aux repos privés dont tu es collaborateur).

Le token commence par github_pat_ (fine-grained) ou ghp_ (classic).

GitLab

Deux options :

• Project access token (recommandé, scopé au repo) :
  1. Repo → Settings → Access Tokens → Add new token
  2. Role : Reporter (suffisant pour git clone HTTPS)
  3. Scopes : cocher uniquement read_repository
  4. Expiration : max 1 an (GitLab.com force ≤ 365 j)
• Personal access token (si tu n'es pas Maintainer/Owner du repo) : Preferences → Access tokens → scope read_repository uniquement.

Token préfixé glpat- (les deux types).

Gitea / Forgejo (self-hosted)

1. Settings → Applications → Generate New Token
2. Permissions : Repository → Read
3. Rien d'autre coché (ni Package, ni Organization, ni Admin)

Bitbucket Cloud

• Repository access token (recommandé, scopé au repo) : Repo → Repository settings → Access tokens → Create Repository Access Token → scope repository:read.
• Alternative : App password (Personal Settings → App passwords) avec Repositories: Read. Username = ton user Bitbucket, password = l'app password généré.

Où est stocké le token ?

Le token est conservé chiffré sur le site, dans sa propre colonne, pour que le bouton Redéployer (git pull) fonctionne sans que vous ayez à le ressaisir. Il n'est rendu par aucune lecture : get_site et list_sites signalent seulement qu'un token existe. L'URL du dépôt mémorisée, elle, est toujours la forme nue, sans identifiants. Si la plateforme n'a pas de clé de service, le token n'est pas conservé du tout : il est refusé plutôt qu'écrit en clair, et vous le repassez à chaque déploiement.

Le token est injecté dans l'URL le temps du clone, puis retiré du .git/config du dépôt cloné avant que celui-ci ne soit copié dans le dossier du site. Ce retrait n'existait pas avant le 17/09/2026 : le .git/config partait avec ses identifiants dans le dossier servi, et pour un runtime servi en fichiers il devenait lisible publiquement.

ZIP upload

Envoie une archive base64 au moment du create.

// Payload
{
  "name": "mon-site",
  "runtime": "static",
  "source_zip": "<base64 du .zip>"
}

• Taille max : 20 Mo
• Payload total create_site : 25 Mo (base64 ~33% overhead)
• Le zip est extrait dans le dossier du site selon le runtime

MCP push_files

Push arbitraire de fichiers dans un repo Gitea Iridflow, sans utiliser git en local. Créé pour les agents Claude Desktop qui n'ont pas accès direct à git.staging.iridflow.com.

// push_files
push_files({
  repo_id: "repo_xxxxxxxx",
  branch: "main",                // default: main
  message: "Update index.html",
  files: [
    { operation: "create", path: "index.html", content_b64: "PGh0..." },
    { operation: "update", path: "style.css",  content_b64: "Ym9k...", auto_sha: true },
    { operation: "delete", path: "old-page.html" }
  ]
})

• 1 seul commit pour tous les fichiers
• auto_sha: true résout automatiquement le sha existant pour un update
• Si le repo est lié au site avec auto-deploy : chaque push_files retrigger le deploy

Deploy manuel

Rebuild l'image Docker + up avec --build. Utile après édition manuelle du code.

// Via UI
Détail site → Opérations → [Deploy]

// Via MCP / REST
POST /api/v1/sites/{site_id}/deploy

Timeout : 10 min. Le status passe à running après succès.

Previews par commit

Déploie un commit isolé sur un sous-domaine dédié <slug>-<sha7>.staging.iridflow.com. Idéal pour tester une PR avant merge, ou faire valider un client sur une v2.

Prérequis : un repo Gitea lié au site.

• Deploy manuel : détail site → Previews → Deploy preview avec SHA complet
• Deploy auto sur push : cocher auto-deploy au link repo
• Quota : 5 previews actifs max par site (GC FIFO au-delà)
• Pin : garde un preview en vie même si nouveau deploy dépasse le quota

Aussi documenté : workflow MCP complet.