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
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
- internal operations
microCI reads a YAML pipeline and generates a Bash script.
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.