Readit NewsWe built Cicada because of our own struggles building CI/CD pipelines. YAML is cumbersome, not type-safe, and does not scale well for large pipelines. Sharing logic across pipelines is hard and most providers don’t let you test your pipelines locally.
Cicada lets you
1. write your pipelines in a real programming language. Using TypeScript gives you type-checking, syntax highlighting, and in-line documentation out of the box. It also lets you extend your pipelines by hooking into the entire TypeScript ecosystem of packages and modules.
2. test your pipelines locally. All jobs are run in containers. This means you can test them with Docker/Podman. It also means you get great caching.
3. run your pipelines on our cloud. Pipelines are checked into your repository and run when triggered by an event in your repository (like a commit/PR), when triggered manually, or at a defined schedule.
We use Deno [0] to create pipeline definitions, Docker Buildkit [1] as our build engine, and Fly [2] for our cloud hosting. Our CLI is written in Rust for speed and stability. The hardest technical challenge we faced was writing BuildKit bindings for Rust [3].
Cicada’s client is fully MIT OSS (the CLI, BuildKit integration, and SDK) [4]. Our dashboard and cloud runners are closed source. The cloud runners have a generous free tier for individuals and are cheap and easy for teams.
You can create and run your first pipeline on your local device by running `npm install -g @cicadahq/cicada`. You can also learn more in our docs (https://cicada.build/docs) or by joining our Discord (https://cicada.build/discord).
In the meantime, I’d love to hear your feedback on what we’ve built!
[1] https://docs.docker.com/build/buildkit/
[2] https://fly.io/
I'll start with Turborepo. Turbo is primarily a task runner for `package.json` scripts with some caching... and that's basically it. If that's all you need, then great, but if you're looking for more functionality, that's where moon comes in. moon is more than just a task runner, we're aiming to be a repository management tool as a whole. This includes project/code ownership, direct CI support, future CD support, code generation, hooks management, constraints, release workflows, and much more. With that being said, we do have a comparison article against Turbo: https://moonrepo.dev/docs/comparison#turborepo
As for Nx, they're more of a competitor than Turborepo. Nx and moon are aiming to solve the same problems, but go about it in different ways. Nx is Node.js based and requires heavy adoption of their ecosystem (@nrwl packages) and their executors pattern. In the long run, this becomes a heavy source of tech debt, as your dependencies are now tightly coupled to their packages and release timelines. With moon, we wanted to avoid this all together. There are no coupled dependencies, and tasks are ran as if you ran them yourself on the command line. No abstraction layer necessary. We also want to embrace a language's ecosystem as much as possible, so moon adoption should be rather simple and transparent (at most each project has a moon.yml file).
But to your last point, we agree, multi-language support is a massive advantage. Having both backend and frontend code in the same repository, powered by the same build system, is a massive win in maintenance costs and developer time saved.
> release workflows
Looking forward for this, especially if that also means auto-publishing of NPM packages, Rust crates, etc.
Could you explain why any existing project using Turborepo/Nx should switch to Moonrepo? What are the advantages and disadvantages? The support for multiple languages seems like a big advantage.
And they do all this work then open source it instead of keeping it as a technical advantage.
Strongly recommend their blog.
Not affiliated just a fan.