Write your pipeline once. Execute it anywhere.
Why microCI exists
Traditional CI systems lock your workflow to a vendor:
- GitHub Actions -> GitHub
- GitLab CI -> GitLab
- Jenkins -> Jenkins
microCI breaks that lock-in.
Define automation in YAML. Generate plain Bash. Run the same pipeline anywhere.
- locally
- on CI servers
- on deployment servers
- in containers
- behind webhooks
What microCI does
Plugins
- bash
- skip
- fetch
- git_deploy
- git_publish
- mkdocs_material
- pandoc
- beamer
- plantuml
- pikchr
- docmd
- doxygen
- clang-format
- cpp
- clang-tidy
- cppcheck
- flawfinder
- jfrog
- minio
- npm
- raspberry_pico
microCI is built around a simple idea:
- write it once
- review it easily
- reproduce it anywhere
It fits many automation use cases:
- CI and CD
- release automation
- documentation generation
- static site publishing
- container building
- firmware delivery
- embedded software delivery
- Raspberry Pi Pico firmware builds
- internal operations
microCI reads a YAML pipeline and generates a Bash script.
For Raspberry Pi Pico projects, see Raspberry Pico plugin.
YAML to Bash
The generated script can be executed directly. No hidden platform. No vendor lock-in.
Execute anywhere
Use the same pipeline definition in different environments:
Why it matters
microCI focuses on:
- pipeline portability
- auditability
- reproducibility
- vendor independence
- local-first execution
The result: one pipeline definition, one source of truth, one script, everywhere.