Sources & Deploy

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 fonctionnel. Aucun input requis, Iridflow génère le code de base directement dans /opt/iridflow/<projet>/<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é

Éditables via SSH ou push_files après création.

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ù stocker le token ?

Le token n'est jamais persisté côté Iridflow. Il est injecté dans l'URL de clone au moment ducreate_site, puis les credentials sont retirés de la config git locale une fois le clone terminé.

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.