Les équipes produit qui livrent en cycles courts veulent un dépôt Git sous contrôle, sans sacrifier les builds iOS natifs. En 2026, coupler Gitea ou Forgejo sur un VPS léger (plan de contrôle : utilisateurs, politiques, webhooks) avec un Mac cloud à la journée (face d'exécution : Xcode, signatures, notarisation) reste un compromis réaliste : le coût fixe du serveur Git reste modeste, tandis que la capacité Apple Silicon n'est facturée que lorsque la file d'attente CI le justifie. L'objectif n'est pas de réinventer GitHub Enterprise, mais de tracer une frontière nette entre orchestration Linux et exécution macOS, avec des jetons à portée minimale et des pools isolés pour les équipes.
Découpage plan de contrôle (VPS) et face d'exécution (Mac cloud)
Sur le VPS, vous hébergez l'API Git, les revues, les protections de branche et la configuration des webhooks ; c'est aussi l'endroit idéal pour un reverse proxy TLS, un pare-feu minimal et une journalisation centralisée. Le Mac cloud ne doit pas exposer Forgejo : il reçoit uniquement des déclenchements authentifiés (webhook signé, jeton de runner, ou file interne) et clone le dépôt en HTTPS ou SSH avec des identifiants éphémères. Cette séparation réduit la surface d'attaque : une compromission du runner n'efface pas votre base d'utilisateurs, et une panne réseau vers le SaaS public n'empêche pas vos équipes de pousser du code sur l'instance auto-hébergée.
Pour les sprints à court cycle, documentez explicitement quels jobs restent sur Linux (lint, tests purs Swift sans simulateur, packaging docs) et lesquels exigent macOS ; une matrice claire évite les doubles pipelines inutiles. Pour creuser le sujet : 2026 — sprint à court cycle : second pipeline macOS CI ou jobs sur agents Linux ? File d'attente, secrets, matrice et FAQ.
| Couche | Rôle | Risques typiques |
|---|---|---|
| VPS + Gitea/Forgejo | Auth, webhooks, miroirs, politique de branches | Fuite de jetons admin, webhook non signé |
| Relais (optionnel) | Queue, rate limit, rejeu idempotent | Double build si pas d'idempotence |
| Mac cloud journalier | Archive, tests simulateur, notarisation | Dérive Xcode, profils expirés |
Webhooks : TLS, signature et anti-rejeu
Exposez Forgejo derrière HTTPS valide ; refusez le HTTP clair pour les callbacks. Stockez le secret de webhook hors dépôt (variables d'environnement du relais ou du runner) et vérifiez la signature fournie par la forge sur chaque POST. Ajoutez un contrôle d'empreinte du dépôt et du SHA de commit attendu pour ignorer les événements dupliqués ou rejoués. Si vous déclenchez plusieurs pipelines (pull request, push sur main, tags), séparez les URL de webhook ou préfixez le corps avec un type d'événement afin de simplifier les audits.
Jetons minimaux : clone, status, artefacts
Créez des comptes machine distincts par pool (par exemple ci-ios-release vs ci-ios-nightly) avec droits en lecture seule sur les dépôts concernés. Limitez les jetons personnels à la durée du sprint et renouvelez-les via votre gestionnaire de secrets. Pour les commentaires de statut sur les pull requests, utilisez un second jeton à portée « issues only » si la forge le permet. Après activation d'un Mac cloud, une checklist concrète pour enregistrer le runner et valider réseau + jetons se trouve ici : 2026, pics CI à cycle court : après activation du Mac cloud — enregistrer le runner, auto-contrôle réseau et jetons minimalistes (checklist 30–60 min + FAQ).
# Sur le Mac cloud — jamais dans le dépôt FORGEJO_URL=https://git.example.com FORGEJO_TOKEN=*** # lecture seule + scope minimal WEBHOOK_SECRET=*** # vérifié côté relais avant exécution
Matrice — isolation des pools entreprise
Les grandes organisations mélangent souvent applications réglementées et prototypes internes. La matrice ci-dessous aide à décider si deux projets peuvent partager le même Mac cloud ou le même compte machine Forgejo. Lorsque la ligne « même runner » est interdite, provisionnez des nœuds ou des comptes séparés et des caches DerivedData disjoints pour éviter la fuite d'artefacts signés.
| Critère | Partage possible | Action recommandée |
|---|---|---|
| Même certificat de distribution | Oui si équipe unique | Sinon, pool + trousseau séparés |
| Données personnelles dans les logs | Non | Runner dédié + masquage des secrets |
| Prestataire externe | Non par défaut | Compte lecture limité + audit webhook |
| Branches protégées identiques | Oui | Politique Forgejo alignée sur GitFlow |
FAQ — incidents et cycle court
Les webhooks arrivent en rafale avant merge
Coalescez côté relais : ne conservez que le dernier SHA de la branche pendant une courte fenêtre, sauf pour les tags semver où chaque événement doit produire un artefact traçable.
Le Mac cloud est saturé en fin de sprint
Réservez des créneaux release et déplacez le lint reproductible sur Linux. Si la saturation vient aussi de quotas minutes côté SaaS Apple, voyez la trajectoire de retour Mac cloud décrite dans 2026 — forfaits minutes Xcode Cloud et concurrence saturée : signaux pour basculer Archive, notarisation et TestFlight vers un Mac cloud à la journée, trajectoire et matrice de retour — FAQ.
Forgejo vs Gitea ?
Webhooks et jetons restent comparables ; tranchez sur gouvernance, cadence de correctifs et extensions. Le schéma VPS + Mac ne change pas.
Sur Mac mini M4 dans le cloud, la face d'exécution iOS tient la cadence
Lorsque Forgejo déclenche vos builds, ce qui compte côté exécution, c'est un macOS stable avec Xcode à jour, une mémoire unifiée Apple Silicon qui absorbe les pics du linker Swift, et une consommation idle d'environ 4W pour les files nocturnes sans bruit ni surchauffe. Gatekeeper, SIP et FileVault offrent une surface de confiance nettement plus simple à expliquer en audit qu'une ferme de PC hétérogènes, ce qui accélère les validations sécurité des pools entreprise.
Comparé à des postes Windows équivalents sur le papier, le Mac mini M4 reste en avance sur le rapport performance / énergie et sur la prévisibilité des builds Xcode ; l'écosystème Homebrew, SSH natif et outils en ligne de commande réduisent le temps perdu en contournements. Pour les équipes qui enchaînent webhooks et signatures, cette cohérence matérielle-logicielle diminue le coût total de possession.
Si vous standardisez la face d'exécution iOS sur du matériel Apple Silicon géré, le Mac mini M4 cloud VPSSpark est un point d'entrée particulièrement rentable — découvrir les offres Mac cloud et aligner vos runners sur une base unique.