Pipelight: small pipelines defined in the config language you already use

A CI-shaped tool with no CI server

Pipelight is a Rust based small, 13MB, command line tool to be used from inside a terminal, and the project describes its purpose in one line: tiny automation pipelines, bringing CI/CD to the smallest projects. The design decision that follows from that is the one that matters most when you evaluate it. The tool is self-hosted, lightweight and CLI only, so there is no service to sign up for, no runner fleet to configure, no web interface to learn and no account to create. A pipeline is a file in your repository, and the commands in it run on the machine you are standing at. That is the right shape for a solo maintainer or a three person project where a hosted CI service costs more in setup than the automation saves. It is the wrong shape for a team that needs the same pipeline to run on ten machines with the same guarantees, and the project does not pretend otherwise.

One pipeline model, six ways to write it

The abstraction is deliberately small. Pipelines fold your bash commands into an object of the shape Pipeline{ Step{ Command }}, and the interesting part is that the object can be written in whichever configuration language you already use. The README shows the same pipeline in TOML, with named pipelines, arrays of steps carrying command lists, and trigger blocks:

[[pipelines]]
name = "test"

[[pipelines.steps]]
name = "build"
commands = ["pnpm install", "pnpm build"]

[[pipelines.triggers]]
branches = ["master","dev"]
actions= ["pre-push", "pre-commit"]

HCL, YAML and JavaScript express the same structure, and the TypeScript variant adds helper shorthands that build a pipeline from a function:

const my_pipeline = pipeline("build website", () => [
    step("clean directory", () => [`rm -rf ${build_dir}`]),
    step("build", () => ["pnpm install", "pnpm lint", "pnpm build"]),
    step("send to host", () => [`scp -r ${build_dir}`]),
    step("do stuffs on host", () => [
      ssh("host", () => ["systemctl restart nginx"]),
    ]),
  ]);

The examples directory carries a file for each format, including a Pkl example alongside the TOML, HCL, JavaScript, TypeScript and YAML ones, and the Rust workspace has a crate called cast whose job, in the project's own comment, is to read multiple file formats and cast them to pipelight config. One model, several front ends, one binary.

Triggers come from git hooks or a file watcher

Automatic triggers are the feature that turns a script into a pipeline. The README's framing is the use case: run tests on file change, or deploy to production on push to master. Two mechanisms are enabled by a command:

pipelight enable git-hooks
pipelight enable watcher

The git hook approach installs hooks into the repository and then works with the trigger block in the configuration, where branches and actions are listed:

[[pipelines.triggers]]
branches = ["master"]
actions = ["pre-push"]

The watcher is the other half, driven by file changes rather than by git, and it shares the same pipeline definition. Both are opt-in, which is the right default for a tool that runs commands on your machine, and both are per repository, since the configuration lives in the project root. A detail worth noting is the .pipelight_ignore file in the repository root, which is how you keep a watcher from reacting to everything the build itself writes, and the .envrc file, which points at a directory environment for local development rather than at something the tool needs at runtime.

init, run, logs: the whole interface

The command line is three verbs and a set of flags. The first command creates a default configuration file named pipelight.ts in your project root directory:

pipelight init

From there you run the default pipeline, which the README calls harmless:

pipelight run

And you read the results afterwards. The plain form gives you the pipeline status, the event, the execution time and similar summary information:

pipelight logs

The verbose form is the interesting one. With -vvvv you get transparent outputs of every subprocess, which is what you want when a step fails inside a script and you need to see the real output rather than a summary. Two levels of logging for a tool that mostly wraps other commands is the right amount of ceremony, and the difference between a summary view for a passing pipeline and a full trace for a failing one is what makes the tool usable without a debugger. Installation itself is left to the documentation, which has an install guide covering the package managers, since the README deliberately does not duplicate it.

A Rust workspace of fifteen crates, including a wasm target

The Cargo manifest describes a workspace with a long member list, and the comments explain the shape of the project. Error handling sits in pipelight_error, which uses miette to read and parse files with fancy error output, and pipelight_config and pipelight_utils hold the small shared pieces. Process management is split into pipelight_exec, pipelight_git, pipelight_teleport and pipelight_watcher, the last being described as a sane and reusable watchexec configuration. The templates crate exists to generate a default pipelight configuration, the cast crate reads multiple file formats and casts them to pipelight config, and workflow, cli, pipelight and man form the core and the entry points. There is also a deno_lib member marked as wasm, which is a hint about where the project is heading with a scripting runtime. The dependency list is equally telling: toml with order preserved, hcl-rs, serde_yaml, serde_json, thiserror, miette, log and bon, with long term release builds compiled with link time optimisation. The presence of flake.nix, shell.nix, package.nix and a rust-toolchain.toml means the toolchain is pinned for reproducible builds.

Single author, no tagged releases, GPLv2

The project is maintained by one person, Areskul, and says so in the copyright line, with the community reached over Discord, Telegram and email. The repository also carries a CHANGELOG.md and a ROADMAP.md, and a STRUCTURE_AND_FUNCTIONING.md, which together suggest the project is planned rather than improvised. What it does not have is tagged releases: there are no GitHub releases, so the version you get is whatever the build produced, and the changelog is the only account of what changed. The last push was on 2026-06-30, which is inside the six month window, so the code is not abandoned, but the absence of release tags means there is no stable channel to pin to and no upgrade notes to read before a version change. The licence is GNU GPLv2, which is the right thing to check if you intend to redistribute the binary, and the 13MB footprint means shipping it inside a product image is cheap.

Editorial conclusion

Pipelight fits a small project that wants the same convenience a CI service offers, from a binary on your own machine, with the pipeline definition committed next to the code. It does not fit a team that needs hosted runners, a web interface, build history across machines or a secrets store, and you should read the pipelight docs install page before assuming your package manager is covered. Before adopting it, check the CHANGELOG.md, because the project tags no GitHub releases, and confirm that the triggers you need, such as a pre-push hook or a file watcher, match how your team actually commits.

Frequently asked questions

Official sources

1. crocuda/pipelight on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README