Open source CLI for GitHub Actions and GitLab CI
One command.A whole repository.
quoll new creates your projects, their Dockerfiles, one pipeline and the repository on GitHub or GitLab, protected and green on the first push. Already have a repo? quoll suggests a pipeline that fits it.
- Angularfront end
- Expressback end
- Node 24runtime
- GitHubhosting
- Kubernetesdeploy to
One command
- frontAngular app, linted and tested
- backExpress API, tests and /health
- Dockerfilesand compose.yaml to run it all
- Helm chartsstaging and production
- One pipelinefor both projects
- acme/shopon GitHub, main protected
A real start, not a skeleton.
A template hands you folders and a to do list. quoll new hands you a repository that already builds, tests, ships and passes its first pipeline.
A starter template
Folders and a README
Then, on your own:
- Write the Dockerfiles
- Wire the front end to the API
- Set up the CI, lint, tests and scans
- Create the repository, protect main
- Fix the pipeline until it passes
quoll new
- Projects that build, lint and test
- A Dockerfile each, and compose.yaml to run them together
- The front end already talking to the API
- One pipeline that passes on the first push
- The repository, created and protected
- Delivery and Helm charts, if you want them
Starters today: Angular and Express, at the version you choose. More through plugins.
Already have a repo? A pipeline that fits it.
quoll ci init reads your project and suggests the checks that fit its stack. A Django app, a Next.js app and a Rust service each get their own.
bookings
LintPython
ruff and mypy
Django checksDjango
system checks, missing migrations
TestsPostgres
pytest against a real Postgres
Dependency audituv
pip-audit on the lockfile
Secret scanning
leaked keys blocked
Static analysis
risky code caught
SBOM and licenses
forbidden licenses blocked
Docker imageDocker
gunicorn, scanned by Trivy
You don't explain your project to quoll. It reads it, suggests what fits, and keeps everything in step as the project grows.
Suggestions that fit your repo.
The choices you'd normally research and copy from a blog post. quoll proposes an answer for each one, drawn from your project. You keep the last word.
0
suggested from your project
0
asked, with a default ready
0
to look up
Which Python version?
Which package manager?
Which linters?
Which test runner?
Databases for the tests?
How does the app start?
Which CI?
Which base image?
How to audit dependencies?
Secrets and risky code?
Minimum coverage?
Who can merge into main?
Every suggestion lands in quoll.toml, where you can change it any time. Happy with them all? Add --yes.
Whatever you build with.
Nine languages and their main frameworks, each with the tools that fit it.
Python
Node.js
Go
Rust
Java
PHP
Ruby
.NET
C/C++
Change a line. Everything follows.
The CI, the Dockerfile and compose.yaml read the same quoll.toml, so they can't disagree. With quoll's pre-commit hooks, they update on commit.
quoll.toml
CI pipeline
- Lint with ruff and mypy
- Tests fail under 80% coverage
- Tests start Postgres
- Audit, secret scanning, Semgrep
Dockerfile
- Python 3.13 slim, non root
- uvicorn listens on port 8000
- Dependencies from uv.lock, cached
compose.yaml
- The API on port 8000
- Postgres, with a healthcheck and a volume
- The API starts once they're healthy
Security checks suited to your stack.
quoll suggests the scans that fit your project: secrets, dependencies, risky code, a coverage gate. Keep them, tune them, or turn one off in quoll.toml.
Lint
ruff, mypy
Tests
212 passed, 84% coverage
Dependency audit
no known vulnerability
Secret scanning
no leak in the history
Static analysis
Semgrep, no finding
SBOM and licenses
no forbidden license
Your next pipeline is one command away.
Open source, MIT licensed, and it runs on your own runners.