Solder
GitOpsEvery Kubernetes cluster exactly as Git says. And when a deployment fails, you know why.
A lightweight Kubernetes operator that keeps clusters in line with Git. It handles approvals and drift detection, and rolls back on its own. No database, no queue, no extra UI to run.
GitOps that turned into its own platform
GitOps is supposed to make deployments predictable. Instead, the popular tools have grown into platforms, with their own databases, caches and dashboards to run and secure. An approval is often just a button, with no link to what was actually reviewed. And when a rollout fails, someone still digs through pods and events to find the missing Secret. Solder does the core job in a single operator, and it explains its own failures.
Why it’s built the way it is.
One operator. Nothing else to run.
No Redis, no PostgreSQL, no message queue, and no UI you’re forced to host. Git, Kustomize and Helm run inside the controller, which never starts a helper program.
Approvals tied to the exact plan
An approval is recorded under the approver’s own Kubernetes identity, against the digest of the plan they reviewed. If that plan changes before it’s applied, the approval no longer counts.
Failures that explain themselves
When an application goes unhealthy, Solder follows the live resources down to the root cause and records it. A missing Secret, say, or an image that can’t be pulled.
Least privilege, per application
Every application deploys as its own service account. Plain Kubernetes RBAC decides what it’s allowed to change.
From setup to everyday use.
- 1
Point it at Git
A Repository resource names a branch, tag or commit, and takes its credentials from a Secret. Solder polls it, or fetches straight away when a signed GitHub or GitLab push webhook arrives.
- 2
Declare the applications
Applications render plain manifests, Kustomize or Helm charts, from Git or from Helm and OCI chart repositories. Solder can also discover them from a .solder.yaml file in the repository.
- 3
Review the plan
Each change becomes a Revision with a field-by-field plan, secrets redacted. Automatic sync applies it. Manual sync waits until someone approves that exact plan.
- 4
Apply, observe, roll back
Changes go in with Server-Side Apply and every resource’s health is checked. If a rollout fails, it can roll itself back to the last healthy Revision.
See Solder at work.
What it does, in detail.
Deployment
- Manifests, Kustomize and Helm Rendered in process, from Git or from Helm and OCI chart repositories.
- Ordered rollouts dependsOn, sync waves, and pre- and post-sync hooks set the order things roll out in.
- SOPS-encrypted Secrets Secrets stored encrypted in Git are decrypted when the manifests are rendered.
- Image automation ImagePolicy watches registries and commits new image versions back to Git.
- Push webhooks A signed GitHub or GitLab webhook triggers a fetch right away. No waiting for the next poll.
Control
- Plan before apply Each Revision carries a bounded, redacted plan: what will be created, what changes, what gets deleted.
- Exact-plan approvals A manual approval is tied to the plan digest and recorded under the approver’s identity.
- Audit history Revisions record who approved what, when it started and finished, and how it ended. Export it all as JSON.
- Ownership conflicts fail by default Fields that another tool owns stay as they are, unless you choose to adopt them.
- Notifications Lifecycle events are sent to webhook or Slack endpoints.
Reliability
- Drift detection and self-heal Changes made directly in the cluster are spotted. If you want, they’re put back to what Git says.
- Health for any kind Health checks built in, and CEL HealthCheck rules for custom resources.
- Automatic rollback When a rollout fails its health checks, it can roll back to the last healthy Revision.
- Root-cause diagnosis solder diagnose prints the chain from the unhealthy resource to what caused it.
- High availability Several replicas, with leader election.
Operations
- Command-line tool List applications and read their plans and history. Approve, roll back, suspend and diagnose from the terminal.
- Prometheus metrics The standard controller metrics, ready for the monitoring you already have.
- OpenTelemetry tracing Configure an OTLP endpoint and every reconcile is traced.
- Migration guides Step-by-step guides for bringing applications across from Argo CD and Flux, with no redeploy.
Who uses it, and for what.
Regulated production changes
Banks and other regulated teams can insist on a named approver for every production change. The approval is tied to the exact plan and kept as an audit record.
Lean platform teams
You want GitOps, not another database, cache and dashboard to operate. Solder is one operator, installed with Helm.
Leaving Argo CD or Flux
Follow the documented migration steps to take over existing applications. Solder adopts the fields the old tool owned, so nothing is redeployed.
At a glance
- Runs on
- Any Kubernetes cluster
- Deployment
- A single operator, installed with Helm or plain manifests; cert-manager provides its webhook certificate
- Sources
- Git over HTTPS or SSH; Helm chart repositories and OCI registries
- Integrates with
- GitHub and GitLab webhooks, SOPS, Slack and webhook notifications, Prometheus, OpenTelemetry
- Interfaces
- Kubernetes custom resources and the solder command-line tool
- Built with
- Go and controller-runtime
Questions
Does anything leave our cluster?
No. Solder runs inside your cluster. It only connects out to what you configure: Git remotes, chart repositories, registries, notification endpoints and the trace collector. Secret values never show up in plans or in command-line output.
Do we need a separate database or dashboard?
No. Everything Solder knows lives as Kubernetes resources. You manage it with kubectl and the solder command-line tool.
We already run Argo CD or Flux. How hard is the move?
There’s a step-by-step guide for each. Solder can adopt the fields the old tool managed, so your applications come across without a redeploy.
Is it ready for production?
Yes. Controller, command-line and end-to-end tests cover it, and we help clients plan the rollout and later upgrades.
How is it priced?
It depends on how many clusters you run and the support you need. Book a demo and we’ll go through it with your own repositories.
Your models, your hardware, your rules.
FastLLM Proxy
An OpenAI-compatible gateway in front of your own LLM servers and 80 hosted providers. Routing, budgets and access control live in one place.
Learn moreAgent, model and GPUaaS platformKuvryn AI
The platform for running AI agents, models and GPUs as a service. Teams run their agents and models on your own GPU servers, each in its own space, all from one console.
Learn moreAI application platformKuvryn
A self-hosted platform for AI applications on Kubernetes. See each application with its parts and its health, and when something breaks, the reason why.
Learn moreAI, automation and CI/CD/CT platformDhole
One workflow engine for build pipelines and infrastructure automation that also orchestrates AI agents, with a person approving where it matters.
Learn moreSee it on your own data.
We run the demo with your data, then propose a scope and pricing.