Fleet

Fleet is a lightweight CI/CD orchestrator written in Rust.
Unlike traditional CI/CD systems (GitHub Actions, GitLab CI, Jenkins…), Fleet is designed to run directly on your host machine (Raspberry Pi, server, VPS, NAS…).

It continuously watches your repositories, detects changes, and runs your deployment pipelines locally, without relying on external cloud services or heavy infrastructure.

Think of it as a local CI/CD daemon:
just git push → Fleet pulls, rebuilds, and redeploys on your machine.

---

Summary

• Why Fleet?
• Features
• Quick Start
• Commands
• Configuration
• How It Works

---

Why Fleet?

Most CI/CD solutions are:

• Cloud-first → require GitHub, GitLab, or external runners.
• Heavyweight → need databases, web servers, complex setup.
• Overkill for small projects.

Fleet is different:

• Lightweight → a single Rust binary, no dependencies.
• Local-first → runs directly on your host (perfect for Raspberry Pi, homelab, VPS).
• Simple → configure with a fleet.yml, and Fleet takes care of pulling & redeploying.
• Connected → supports notifications (Discord for now, more to come).

Features

• Watch multiple repositories at once
• Automatically detect new commits on remote branches
• Execute update scripts when changes are found
• Per-project logs accessible via CLI
• Start, stop, and resume repository watches dynamically
• YAML-based configuration for flexible update workflows
• Parallel and sequential job execution in pipelines
• Detect cyclic dependencies in pipeline jobs
• Optional per-step environment variables and container execution
• Respect blocking and non-blocking step configuration
• Notifications on pipeline completion (only discord for now)
• Statistics overview of watched projects with CPU/memory usage and success/failure counts

---

Quick Start

# Clone the repository
git clone https://github.com/pepedinho/fleet.git
cd fleet

# Install fleet
make install

Add your first project:

fleet watch

---

Commands

Command	Description
fleet watch	Add a project to the watch list (run inside the project dir)
fleet logs [id|name]	Show logs for a project (current dir by default) (-f to follow logs)
fleet ps	List watched projects (-a to show stopped projects)
fleet stop <id>	Stop watching a project
fleet up <id>	Resume watching a stopped project
fleet rm <id>	Remove a monitored project
fleet stats	Show interactive statistics of all watched projects
fleet run <id>	Run a pipeline on demand

---

Configuration

Each project defines its pipelines with a fleet.yml file.

Example fleet.yml:

Here’s how I use Fleet to auto-update my Discord bots running on a Raspberry Pi:

ENV: &default_env
  DISCORD_TOKEN: $
  D_WEBHOOK_G: $
  D_WEBHOOK_T: $

branches: ['*'] #you can use wildcard for all or directly a list of branches

timeout: 800

pipeline:
  notifications:
    on: [success, failure]
    thumbnail: https://github.com/user-attachments/assets/429bf6e8-5724-473e-a560-e9e06bbbc143
    channels:
      - service: discord
        url: https://discord.com/api/webhooks/...
  jobs:
    pull:
      steps:
        - cmd: echo "Start update"
        - cmd: git pull
    
    down:
      steps:
        - cmd: docker-compose down
    
    deploy:
      needs: [down, pull]
      env: *default_env
      steps:
        - cmd: docker-compose up --build -d

➡️ Now, every time I push to main, Fleet automatically pulls the code and redeploys the bot — no manual SSH, no manual Docker restart.

Key Points:

• timeout → global timeout for async jobs (default 300s).
• needs → define dependencies between jobs.
• blocking: true → fire and forget.
• env → per-step environment variables.
• container → run step in Docker container.
• notifications → external alerts (success/failure).

---

How It Works

Detailed workflow

1. fleetd runs in the background and periodically checks repositories.

2. When a new commit is detected:

   • Jobs are executed respecting dependencies.
   • Independent jobs run in parallel.
   • Failures propagate and block dependent jobs.
   • Cyclic dependencies are detected and reported before execution.
   • Environment variables and containers are supported per step.
   • Notifications are sent to configured channels (Discord, webhook, etc.).

3. Logs for each project are stored and retrievable via fleet logs.

4. Global statistics are available via fleet stats.

---