3/ Extensions add capabilities. They don't add risk.
Each one runs in a sandbox. Deny-by-default. Independent upgrade cycles.
This is how LabHit works. Modular isn't just cleaner. It's safer.
2/ The alternative: modular.
Minimal engine core (12MB, 1.7MB RAM). Execute pipeline DAGs. That's it.
Everything else — cloning, builds, tests, deploys, notifications — is a sandboxed extension.
Install what you need. Remove what you don't.
1/ Monolithic CI/CD is the new legacy.
15,000+ GitHub Actions marketplace entries. 1,800+ Jenkins plugins. GitLab CI shipping 40+ built-in templates.
These platforms grow until they collapse under their own weight.
Question for the devops crowd:
What's the ONE thing you'd change about your current CI/CD setup?
Build times? Config complexity? Plugin management? Something else?
We're building a CI/CD engine from scratch and want to hear what actually matters.
2/ Our spec is already public: github.com/Lab-Hit/lab...
Interface definitions, schema, example manifests. Open for review before the engine launches.
Trust starts with transparency.
1/ LabHit is Apache 2.0 from day one.
Not "open core with a catch." Actual open source.
CI/CD is infrastructure. You need to trust it completely — read the code, audit the security, extend it freely, fork it if we disappear.
LabHit pipeline vocabulary:
use: — which extension
after: — DAG dependencies
sandbox: — isolation
gate: — policy checks
run: — inline commands
Five keywords. No YAML inheritance. No expression soup.
Pipelines should be readable by the whole team, not just the one person who wrote them.
The result: a CI/CD engine where YOU decide what's installed.
Minimal core. Infinite extensibility. That's the model.
Every extension runs in a sandbox.
Deny-by-default. Can only access explicitly granted resources.
No extension can reach outside its sandbox. No bloated platform. No wasted resources.
"Install capabilities, not plugins."
LabHit ships with zero built-in integrations. Everything is an extension.
source/git, build/container, test/runner, scan/dependency, deploy/kubernetes, notify/slack
You install what you need. Nothing more.
385 tests. Zero clippy warnings. 10 crates.
Every core subsystem tested: scheduler, containers, events, policy, extensions.
We don't ship without tests. Quality-first isn't a slogan — it's how we actually build.
The test count goes up every session. It never goes down.
The Rust CI/CD ecosystem is real: tokio, axum, serde — all production-grade.
Harder to write. Faster to run. Safer by default.
That's the trade we'll take every time.
What we get:
- 12MB binary, 1.7MB RAM at idle
- Async pipeline scheduling (no GC pauses)
- Compile-time safety for every input parser
- 385 tests, zero clippy warnings
Why Rust for a CI/CD engine?
Not hype. Practicality.
CI/CD handles untrusted code in production 24/7. Memory bugs aren't acceptable. GC pauses aren't acceptable.
Rust eliminates both.
We designed our own pipeline language. Five keywords:
use → install an extension
run → execute a command
after → declare deps
gate → enforce policy
sandbox → isolate execution
No YAML inheritance. No vendor lock-in.
#DevOps #CICD #RustLang #BuildInPublic #OpenSource
LabHit Extension Catalog: 6 sandboxed WASM extensions in category/name format. source/git, build/container, test/runner, scan/vulnerability, gate/require-review, deploy/kubernetes. Dark theme with colored accent bars.
Every CI/CD platform ships everything by default. We think that's backwards.
LabHit ships a tiny core. Everything else is a sandboxed extension:
→ source/git
→ build/container
→ scan/vulnerability
→ gate/require-review
→ deploy/kubernetes
What would you add?
#DevOps #Rust #OpenSource
Great question. Three things:
Memory safety without a GC — untrusted extensions in sandboxes means you can't afford host crashes. Rust catches those at compile time.
Async parallelism — stages run concurrently off a DAG, no thread-per-stage overhead.
Single binary — runs on a laptop or cluster.
The spec is public today. The engine ships when it's ready.
Follow along as we build in the open:
🔗 labhit.dev
📋 github.com/Lab-Hit/labhit-spec
If you're into Rust, WASM, or think CI/CD needs a rewrite from scratch — let's talk.
This isn't a pitch deck. It's running code.
✓ 9 Rust crates, full test suite passing
✓ Pipeline orchestration with parallel execution
✓ Container sandboxing via Docker
✓ Policy engine (default-deny, fail-closed)
✓ WASM extension runtime
✓ GraphQL API
All open source. Apache 2.0.
No YAML spaghetti. No vendor lock-in. Your pipeline speaks a clean vocabulary:
use: source/git
run: cargo build --release
gate: policy/require-sign
sandbox: container
Install what you need. Nothing more.
CI/CD shouldn't be a monolith.
We're building LabHit — a modular CI/CD engine in Rust. A tiny core handles scheduling, isolation, and policy. Everything else is a sandboxed WASM extension you install at will.
First post. Let's build in the open. 🧵
