Resize checkout-api CPU request 2.0 → 1.2 cores
- ReplayedBusiest hour Tue 09:00 UTC · peak 0.91 cores
- Headroom32% above observed peak
- Saves$184 / month at list price
Kubernetes operations, governed
Autonomous infrastructure operations you are actually allowed to install.
Every change to a Kubernetes fleet — a release, a config edit, a right-sizing, a node reduction, a coding agent's deploy — through one ledger, with a replayed safety argument and a record of what the system refused to do.
Applied checkout-worker memory limit 2 GiB → 1.5 GiB
- Approvedm.okafor · 14:02:01 UTC
- Read back14:02:07 UTC · matches
- OwnerNone — Seylo field manager
Resize cart-api CPU request 2.0 → 1.4 cores
Refused: below observed peak (1.8 cores, Tue 09:00 UTC)
The pain
Every operator wants the automation. Nobody is allowed to install it.
Cost tools ask for the keys
The tools that can cut 40–60% of a Kubernetes bill need cloud-account write access and act on their own. In most organisations that is not a technical problem — it is a permission security and change control will not grant.
Reconcilers don't approve
Argo CD and Flux converge a cluster on a commit. They have no opinion on whether the commit was wise, who authorised it, or what it will cost.
Coding agents now deploy
Every Kubernetes MCP server shipping today is kubectl apply handed to a language model. Convenient — and a prompt-injection incident waiting to happen.
49%
say Kubernetes drove costs up
<25%
of requested CPU is used
0
tools that can show an auditor why the system refused to act
Who it is for
Built for the team that gets asked “who approved that?”
Platform lead
“I want the savings. I cannot install a black box in production.”
Security & compliance
“Show me who authorised the change, under what policy, and prove it landed.”
Developer with a coding agent
“My agent wrote it. I want it deployed — through the front door, not around it.”
The promise
Autonomy is earned, rung by rung.
Rung 0
Observe
30 days of per-container usage, an hour-of-week profile, a seasonally adjusted trend, real list prices.
Rung 1
Propose
One plan: resize, unblock, remove a node. Every item carries a replayed safety argument — and an explicit list of what was refused, and why.
Rung 2
Approve
A human approves per change. Every write is read back to prove it landed; a reverted change is reported as drift, not success.
Rung 3
Envelope
An admin signs a bounded, expiring, rate-limited grant; the engine acts inside it unattended. Kill switch. Auto-suspend after three failures.
Rung 4
Earned
After clean executions and recorded refusals in a decision class, promotion to unattended is itself an approval, evidenced by the ledger.
The refusals are the asset. No one else can produce evidence of restraint — and that is exactly what a risk committee needs before granting standing authority.
How it works
Five steps. Nothing changes without a signature.
The product
A console people want to be in.
-
Fleet dashboard
Every cluster and namespace, with the image tag each component is running right now.
-
Approvals with a per-kind view
A release, a config edit and a resize each render as what they are — diff and safety argument beside the button.
-
Additive config edits
Environment and ConfigMap changes that add and update keys. Nothing is silently dropped.
-
Risk-tiered resources
Generic Kubernetes resources in four tiers; the write path narrows as the tier rises.
-
Posture with generated remediation
Each policy finding arrives with the proposal that would fix it, ready for approval.
-
Cost & proposals
Real list prices, a 30-day baseline and a plan you approve item by item — refusals listed.
The second door
Coding agents plug in. We run the infrastructure.
Your developers already ship through Claude Code, Codex or Cursor. Those agents stop at the commit. Everything after it — image, manifest, environment, rollout, right-sizing — is infrastructure work, and it is exactly what Seylo does. A coding agent asking Seylo to deploy is just another requester in the same approval flow.
Shipping in the next two releases
- Coding agentWrites the code and the Dockerfile
- Hosted MCPPropose-only tools, capped at releaser
- Build in their clusterA Kubernetes Job, workload identity, their registry
- LedgerRequested by, on behalf of, approved by
- Verified rolloutApplied, read back, signed image with SBOM
The hosted MCP server
A thin remote MCP over the API that already exists. OAuth device flow against your SSO; a per-developer identity capped at the releaser role; no cluster or registry credential anywhere in it. The tools are propose-shaped, never apply-shaped — the agent cannot bypass approval.
Builds inside your cluster
The in-cluster agent runs the build as a Kubernetes Job — rootless BuildKit, or Buildpacks when there is no Dockerfile — and pushes to your registry with workload identity. Source travels from your git host to your cluster and nowhere else. The image is signed with cosign and carries an SBOM.
What we deliberately do not do
- Host a build farm.
- Receive source code.
- Hold a registry credential.
Those are the three things that would make Seylo another party your security team has to trust. The product exists to avoid being that party.
Principles
Non-negotiable.
-
Never invent a number.
Unknown means “unpriced, because X” — never an estimate from a similar SKU. A refusal states its reason.
-
Propose-and-approve is the default.
Autonomy exists only inside an envelope that is signed, bounded, expiring and rate-limited, with auto-suspend after three failures and a tenant-wide kill switch.
-
No cloud credentials. No exec.
Node-layer savings come from in-cluster policy objects or IaC changes you review — never from Seylo calling a cloud API.
-
Secrets are write-only.
No endpoint, page, log, audit row or export ever returns a Secret value.
-
Coexist with Argo, Flux and Helm.
A write to a resource owned by a reconciler is refused unless explicitly acknowledged, and the message names the owner and the consequence.
-
Verify, don't assert.
Every write is read back. Every judgement lives in a pure module with tests; every I/O path contains no judgement.
Roadmap
Monthly, in this order.
-
v1.0 now
The MVP
Fleet dashboard, bundled releases, approvals, additive config edits, risk-tiered resources, posture, cost & proposals, the envelope stored and validated, SSO, audit.
-
v1.1
The coding-agent door
A hosted MCP server, propose-only, capped at the releaser role. Your agent asks; a human approves.
-
v1.2
In-cluster builds
Commit to signed image as a Kubernetes Job in your cluster, pushed to your registry with workload identity.
-
v1.3
The envelope acts
The executor is wired: bounded, expiring, rate-limited, with a kill switch and auto-suspend after three failures.
-
v1.4+
Node-layer savings, earned autonomy, evidence export
Karpenter and cluster-autoscaler policy writes, per-node usage, promotion to rung 4 inside the product, signed evidence export for auditors.
Every operator wants the automation. Nobody is allowed to install it.
We are selling the permission slip.
Design partnership
Request a design partnership
We are looking for three platform teams on AKS, EKS or GKE with a real bill and a real change-control process. You get the product and our attention; we get the truth.
Email us
hello@seylo.example