Files
wiki/Catalogue-Self-Hosted/apps/app-rapidforge.md
T
2026-06-09 18:40:21 +02:00

5.6 KiB


title: RapidForge created: 2026-06-07 updated: 2026-06-07 type: app tags: [catalogue, development, ci-cd, build-hosting, self-hosted] confidence: medium contested: false sources: [https://selfh.st/apps/?tag=Development, https://github.com/rapidforge]

💻 RapidForge

Plateforme d'hébergement de builds et de CI/CD jeune et prometteuse — alternative moderne à Travis CI ou AppVeyor, conçue pour être auto-hébergeable et légère.

📋 Informations Générales

Attribut Valeur
Nom RapidForge
Slug rapidforge
Description Hébergement de builds et CI/CD open source (projet jeune)
Site officiel https://rapidforge.io (à vérifier)
Repository https://github.com/rapidforge (à vérifier)
Stars 37
Licence MIT (à vérifier)
Langage Go / Node (à vérifier)
Catégorie Development
Note ⚠️ Projet jeune (~37 ) — adopter avec prudence, API susceptible de changer.

📝 Description

RapidForge est une plateforme d'hébergement de builds et d'intégration continue open source, pensée comme une alternative auto-hébergeable aux services SaaS type Travis CI, CircleCI ou AppVeyor. Le projet se positionne sur la simplicité de déploiement et l'absence de vendor lock-in : un binaire unique, une base de données relationnelle, et un frontal web léger.

Fonctionnalités : déclenchement de builds sur push Git (webhooks), exécution de pipelines YAML, gestion d'agents (runners), interface web de consultation des logs et de l'historique, badges de statut, notifications par email/webhook, et gestion multi-projets. Le modèle économique est 100% open source, sans offre commerciale cachée.

Positionnement : par rapport à app-drone ou app-woodpecker-ci (plus matures, container-native), RapidForge joue la carte de la simplicité radicale — un binaire, une BDD, et c'est parti. En contrepartie, le projet reste jeune, l'écosystème de plugins est limité, et la documentation est encore embryonnaire.

⚠️ Confiance faible : avec ~37 étoiles GitHub et un historique court, l'API peut évoluer rapidement. À utiliser pour des projets personnels ou de petite envergure, pas en production critique sans audit.

🚀 Installation

Via Docker (recommandé)

# docker-compose.yml
version: "3.8"
services:
  rapidforge:
    image: rapidforge/rapidforge:latest
    container_name: rapidforge
    restart: unless-stopped
    environment:
      - DATABASE_URL=postgres://rapidforge:CHANGEME@db:5432/rapidforge
      - SECRET_KEY=CHANGEME
      - DOMAIN=ci.example.com
      - WEBHOOK_SECRET=CHANGEME
    volumes:
      - ./data:/var/lib/rapidforge
      - ./runners:/etc/rapidforge/runners
    ports:
      - "8080:8080"
    depends_on:
      - db

  runner:
    image: rapidforge/runner:latest
    restart: unless-stopped
    environment:
      - FORGE_URL=http://rapidforge:8080
      - RUNNER_TOKEN=CHANGEME
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - rapidforge

  db:
    image: postgres:15-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=rapidforge
      - POSTGRES_PASSWORD=CHANGEME
      - POSTGRES_DB=rapidforge
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Installation manuelle

git clone https://github.com/rapidforge/rapidforge.git
cd rapidforge
go build -o rapidforge ./cmd/rapidforge
./rapidforge --config ./config.yaml

⚙️ Configuration

  • DOMAIN : URL publique HTTPS — utilisée dans les webhooks et badges, doit correspondre au vhost exposé par le reverse-proxy.
  • SECRET_KEY : clé de signature des sessions — openssl rand -hex 32, obligatoire en production.
  • Runners : architecture master/agent, à enregistrer avec un RUNNER_TOKEN partagé.
  • Pipelines : format .rapidforge.yml à la racine du dépôt (à confirmer dans la doc officielle).
  • Backups : pg_dump sur le volume PostgreSQL + export des configurations runners.

🔗 Alternatives

  • app-drone — CI/CD container-native mature, basé sur Docker, syntaxe .drone.yml.
  • app-woodpecker-ci — Fork communautaire léger de Drone, idéal pour homelab.
  • Forgejo Actions — CI/CD intégré aux forges Gitea/Forgejo, compatible GitHub Actions.
  • Jenkins — Le « dinosaure » du CI, très flexible mais lourd à maintenir.
  • Buildbot — CI en Python, flexible pour des cas d'usage exotiques.

🔒 Sécurité

  • Secrets : SECRET_KEY et WEBHOOK_SECRET à stocker dans un secret manager — jamais dans le docker-compose.yml commité.
  • Runners : l'accès au socket Docker de l'hôte équivaut à un accès root — isoler les runners dans une VM dédiée ou un conteneur privilégié dédié.
  • HTTPS obligatoire : Traefik ou Caddy en amont, avec Let's Encrypt.
  • Auth : à coupler avec un OIDC (app-authentik, Keycloak) pour éviter un store d'utilisateurs dédié.

📚 Ressources

🔗 Pages Liées