public digest · 5 picks
This Week: Self-Hosted CI/CD and the Secrets Between Them
This week's picks lean hard into self-hosted infrastructure: four CI/CD systems with wildly different philosophies, and one tool that solves a problem every GitOps team eventually hits — how do you put secrets in a git repo without handing over the keys to anyone with read access.
We didn't pick these because they're new or trending. We picked them because each one represents a real, opinionated answer to a hard operational problem, with years of production use to back it up. Read the heads-ups as seriously as the praise — these are all tools that reward investment and punish half-measures.
// pick 1 of 5
Sealed Secrets lets you encrypt Kubernetes Secrets client-side into a SealedSecret CRD that only the in-cluster controller can decrypt, so secrets can live safely in git repos. It's aimed at teams doing GitOps who need secrets in version control without a separate vault system.
Sealed Secrets solves a genuinely annoying problem cleanly: encrypting Kubernetes Secrets client-side so they can live in git without exposing plaintext to anyone with repo access. The scope mechanism — binding ciphertext to a specific name and namespace by default — is the kind of design decision that shows someone actually thought about the failure modes, not just the happy path. Key rotation works out of the box with sane defaults, and the documentation is refreshingly honest about what rotation does and doesn't buy you.
What to know going in: the controller holding the private key is a single point of failure, and there's no HSM or KMS-backed storage yet — the project admits this gap rather than hiding it. There's also no audit trail for who sealed what, since kubeseal doesn't authenticate the caller by design. And backing up the sealing key is a manual step that's easy to forget until the day you need it and every SealedSecret in your git history becomes permanently unreadable.
View on GitHub → Our full take →
// pick 2 of 5
Playwright is Microsoft's cross-browser automation and end-to-end testing framework, driving Chromium, Firefox, and WebKit through a single API. It's aimed at frontend/QA engineers writing e2e tests, and increasingly at AI agent tooling via its CLI and MCP server for LLM-driven browser control.
Playwright fixed the two things that made browser test suites miserable: flaky waits and slow, unreliable isolation. Auto-waiting and web-first assertions genuinely eliminate sleep() calls, and spinning up a fresh browser context per test is cheap enough that you can actually trust test isolation instead of hoping for the best. Trace Viewer is a real debugging tool — full DOM snapshots, network logs, console output, all scoped to the failing step — not a feature that looks good in a demo and dies in practice.
The project also maintains its own browser patches for Firefox and WebKit instead of just wrapping CDP, which is why cross-browser behavior actually holds together instead of subtly diverging.
What to know going in: the repo has sprawled into a test runner, CLI, MCP server, and VS Code extension, and the README now reads like a routing page more than documentation for one tool. Binary browser downloads add real weight to CI and Docker images. And the AI agent tooling (CLI, MCP) is new enough that you should expect breaking changes for a while.
View on GitHub → Our full take →
// pick 3 of 5
Harness Open Source is a self-hostable all-in-one dev platform combining Git hosting, CI/CD pipelines, cloud dev environments (Gitspaces), and artifact registries, built by the team behind Drone CI. It targets teams who want a GitLab/GitHub-alternative that also bundles CI and container registries into one binary.
Harness is what happens when a team with real CI lineage (they built Drone) decides to bundle Git hosting, pipelines, dev environments, and artifact registries into one binary. The single-binary-with-embedded-UI setup makes local evaluation trivial — one docker run and you're looking at a working platform. The codebase is organized cleanly by domain, which matters a lot for a project trying to do this much.
What to know going in: doing four things at once means a lot of surface area, and the README itself admits Harness pipelines aren't at feature parity with Drone yet — so if you're coming from Drone, migration isn't a solved story. Local dev setup is heavy (specific protobuf and yarn version pinning), and pipelines mounting the host docker socket is a production security question the docs don't really address. There's also no visible story yet for HA, backups, or migration tooling, which matters if you're evaluating this as a genuine platform replacement rather than a toy.
View on GitHub → Our full take →
// pick 4 of 5
Concourse is a container-based CI/CD engine built around declarative YAML pipelines, stateless workers, and a resource-based model for pulling in/out artifacts. It targets teams that want a self-hosted, opinionated pipeline system rather than a hosted CI product, and it's been in production use for years at scale.
Concourse's architecture is genuinely different from most CI tools, and that's the whole appeal: stateless workers, container-per-step execution, and a resource model that makes pipelines reproducible as self-contained YAML rather than depending on hidden CI state. The codebase reflects that design discipline — cleanly split into ATC, TSA, and worker components — and there's an actual RFC process behind design decisions instead of feature dumps landing ad hoc.
What to know going in: the resource abstraction that makes pipelines portable is also the thing that confuses everyone at first — get/put semantics and caching behavior aren't intuitive, and there's a real learning curve before it clicks. There's no GUI for authoring pipelines; everything goes through fly and hand-written YAML, which is a hard sell next to GitHub Actions. And running it means operating ATC, TSA, workers, and Postgres yourself — this is a self-hosted commitment, not a quick setup.
View on GitHub → Our full take →
// pick 5 of 5
Jenkins is the long-standing self-hosted CI/CD automation server, built in Java with a massive plugin ecosystem covering builds, tests, and deployments. It's for teams that need full control over their CI infrastructure and are willing to deal with the operational overhead that comes with it.
Jenkins earns its place here for one reason: the plugin ecosystem. Whatever tool you need to integrate with, there's almost certainly a plugin already, and that's nearly impossible to replicate with newer tools built from scratch. The core is genuinely battle-tested across an enormous range of production environments, with real long-term maintenance across weekly and LTS release lines, and Jenkinsfile pipelines give you real programmatic flexibility that config-only CI tools can't match.
What to know going in: this is a 15+ year old Java codebase, and it shows — legacy classes like Hudson.java are still in there, and plugin quality varies wildly since plugins are maintained by third parties with very different levels of care. Groovy pipeline syntax has a real learning curve, and debugging a failed pipeline is often more painful than it needs to be compared to newer YAML-based tools. Running your own Jenkins instance is real ongoing work — plugin compatibility, security patching, JVM tuning — that hosted CI has mostly made someone else's problem.
View on GitHub → Our full take →
That's the list this week. If you want these picks in your inbox as they happen instead of hunting for them, the email signup on finds.dev takes about ten seconds.
Get this in your inbox →