Raise checkout-worker memory limit 1 GiB → 1.5 GiB
- [1] EventOOMKilled · container worker
- [2] MetricWorking set at the limit before each restart
- [3] Log“JavaScript heap out of memory”
Open from 8 November 2026 · $5 per managed vCPU a month
The SRE agent for your Kubernetes clusters.
Seylo deploys, monitors and takes action on the clusters you already run. It is not a senior SRE yet; that is the job we are building it to do, one verified kind of fix at a time. Today, when an alert fires, Nightshift investigates with numbered evidence, proposes the fix, and verifies it or undoes it. Every change is proposed, approved and read back. The agent connects outbound, and Seylo stores no cloud keys.
Fixed orders-api readiness probe port 8080 → 8081
- Approvedm.okafor · 14:02:01 UTC
- Read back14:02:07 UTC · matches
- CheckedPods Ready · endpoints ready
Resize cart-api CPU request 2.0 → 1.4 cores
Refused: below observed peak (1.8 cores, Tue 09:00 UTC)
Why Seylo
On call, without the 3 a.m. guesswork.
Without Seylo
- An alert fires, and someone opens five tabs to guess at the cause.
- A database slows down and three teams get paged for three different symptoms.
- Observability bills grow with every gigabyte, because the data sits on someone else’s disks.
- The automation you want needs your cloud keys and a shell into your containers.
- An AI acts first and explains afterwards.
- A new tool fights the Argo CD, Flux or Helm you already run.
With Seylo
- When an alert fires, Nightshift gathers the evidence, numbers it, and proposes the fix.
- Related alerts become one incident, walked along the service map to the service where the failure started.
- Metrics, logs and traces stay in your cluster, on your disks. Seylo charges nothing per gigabyte.
- One agent that connects outbound only. Seylo stores no cloud keys, and there is no shell into your containers.
- Every change is proposed, approved by a person, then read back. A fix that does not hold is undone.
- A resource owned by Argo CD, Flux or Helm is refused until you acknowledge the owner.
Who it is for
Built for the team that gets asked “who approved that?”
Engineer on call
“Wake me for the decision, with the evidence already gathered — not for the digging.”
Platform lead
“Fine. But I am not giving a language model my cluster.”
Security & compliance
“Show me who authorised the change, under what policy, and prove it landed.”
The promise
Autonomy is earned, rung by rung.
Rung 0
Observe
Metrics, logs and traces from your own cluster, a service map of what calls what, and alerts grouped into incidents. Nothing is changed.
Rung 1
Propose
Nightshift investigates and proposes the fix, citing numbered evidence. Each fix carries its check and its exact undo — and what was refused is listed with the reason.
Rung 2
Approve
A person approves per change. Every write is read back to prove it landed; a Nightshift fix is then checked against the symptom, and undone if it does not hold.
Rung 3
Envelope
An admin requests and an approver signs a bounded, expiring, rate-limited grant; Seylo acts inside it unattended. Kill switch. Auto-suspend after three failed or reverted changes in a row.
Rung 4
Earned
A low-risk class of fix that people here approved three times, each one verified, may run on its own; five times for medium risk; never for high risk. An admin turns it on, with an end date at most 90 days away.
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
Four steps. Nothing changes without a signature.
The product
A console people want to be in.
What Seylo does
Live today: six capabilities, one governed path into your clusters.
-
Nightshift, the AI SRE
When an alert fires, Nightshift investigates the way an engineer on call does, and answers in an SRE’s order: mitigate, fix, prevent. It acts only with approval, or inside limits you sign.
- It starts on its own when an alert fires, once a model is set. It reads the pods, events, logs and release history, and writes its own metrics, logs and trace queries, which the stores limit to the alert’s namespace. Automatic runs only read and propose, and are capped: 40 a day per organisation by default.
- Every finding must cite the evidence it rests on, by number. A finding with none is dropped before you see it.
- The fix is a remedy you can act on: where the change goes, the exact change, who applies it — Seylo once a person approves, a pull request, the coding agent, or a person — and the signal that will show it worked.
- Each fix Seylo applies carries its check and its exact undo. After an out-of-memory kill, the new limit is sized from evidence: the heap the container declares, its crash log, or the same image running healthy. It must then run 15 minutes with no OOM kill and every pod Ready; if it does not, Seylo applies the inverse and reads it back. A leak is refused, because more memory only delays the crash.
- Some changes always wait for a person, whatever is granted: a workload Argo CD, Flux or Helm owns, a rollback to a revision Seylo did not record, recreating a volume claim, growing a disk, and every mitigation — a capacity buffer, a rate limit, scaling another workload down.
- It follows Seylo’s 45 core runbooks and your own, and remembers one short lesson from each alert it worked on. The memory is your organisation’s: only admins see it, and it can be switched off, exported and deleted.
- It runs on Seylo’s model or on your own key. Without a model, you still get the numbered evidence.
-
Incidents, rooted at the cause
When a database fails, the API behind the front end fails next. That is three alerts and one problem — so Seylo makes it one incident, and Nightshift works it once.
- The service map shows what each workload calls and what calls it, from your cluster’s objects, traces, a service mesh and your Backstage or Seylo architecture files. Every edge says how it is known.
- Alerts the map connects, starting within 15 minutes of each other, become one incident. Seylo walks it to the service where the failure started and lists who else is hit.
- Health signals — consumer lag, queue backlogs, pools and connections at their limit, slow queries — are read from the exporters you already run, so a database that never alerts can still be named as the root.
- One fix on the root, through the right door: in the cluster; as a pull request to the owner’s repository when Argo CD or Flux deploys it from GitHub, once an admin allows it; or as a task for the coding agent when the fault is in the code. Seylo never merges its own pull request.
- Follow one request from a log line or a trace: the path it took, where it dropped, and why.
-
Observability that stays in your cluster
One Helm chart. Metrics, logs and traces are stored in your cluster, on your bill, and queried when you ask.
- A metrics store, a log store and a trace store in your cluster, with a log explorer, traces and APM, host metrics, and dashboards that work as soon as the chart is installed.
- APM coverage lists the workloads that serve traffic but send no traces, and proposes one OpenTelemetry Operator annotation for each — verified by spans arriving, and removed if they do not.
- Alerts you can acknowledge, snooze, assign and resolve with a reason. Uptime checks for public URLs.
- Notifications to email, Slack, Microsoft Teams, Google Chat, PagerDuty, Opsgenie / Jira Service Management or signed webhooks.
- Import dashboards, alert rules and monitors from Grafana, Prometheus, Alertmanager, Datadog or Uptime Kuma. Every item that did not come across is listed with the reason, and your existing tools keep running while you compare.
-
Controlled deployment, alongside what you run
Every change goes through one governed path, and you can always see who made it, under what policy, and that it landed.
- A change is proposed and, with approvals on, approved by a person with the right role, then applied by the agent in your cluster and read back to confirm it landed. A request nobody approves expires after 72 hours.
- A resource owned by Argo CD, Flux, Helm or an operator is refused until someone acknowledges the owner by name.
- Every version of every Deployment, Service and Ingress is kept in a hash-chained history. Roll back by releasing an earlier tag.
- Single sign-on through Entra ID, Google Workspace, Okta or any OpenID Connect or SAML provider. Four roles, and namespace grants that decide what each person can see as well as change.
- Secret values are write-only: no page, log, audit row or export ever returns one.
- In early access: connect an Azure subscription, an AWS account or a Google Cloud project to see what runs in it — read-only, with no key stored. Seylo refuses a role that could change anything or read your data.
-
Cost you can trace
Allocation computed in your cluster. Every price names its source.
- Seylo’s cost engine measures each workload’s share of each node, in your cluster, and rolls it up into chargeback by team or namespace.
- Each price says where it came from: Azure retail, the AWS price list, the Google Cloud catalogue, the Oracle price list, or a sheet you uploaded. Anything unpriced says so, with the reason.
- Cost dashboards from Seylo’s FinOps templates: cost by namespace and workload, idle capacity, requested against used, and each week against the last. A period with no data is never drawn as zero.
- Savings arrive as proposals, each with the usage it rests on, replayed against the workload’s busiest hour. Approve the ones you want. Right-sizing lowers the vCPU you request, so it lowers your Seylo platform fee too.
-
Coding agents, one namespace at a time
seylo-mcp gives Claude Code, or any MCP client, a door into exactly one namespace you open, and nothing else. It is included in the platform fee, deploys and all.
- Each token reaches one cluster and one namespace. It expires after 30 days by default, never more than 90, and allows 20 deploys a day by default.
- Read-only by default: what is running, its logs, and metrics, logs and traces limited to its namespace. It deploys, rolls back or edits config only if you allow it, and only after a policy check and a dry run.
- It never holds a cluster credential, never reads a Secret value, and cannot approve its own change. A deploy that puts a credential in an environment variable is refused; the agent asks a person to create the Secret instead.
- Seylo’s hosted coding agent works on your GitHub repository in an isolated sandbox, runs the tests and a security scan, opens the pull request as you, and proposes the deploy for approval.
How Nightshift is tested
A kind of failure is claimed only after we have broken a workload that way and watched Nightshift handle it.
-
Real failures, in a live cluster
Seylo keeps its own failure zoo: 60 scenarios of the ways Kubernetes workloads break, injected into a live cluster we run for the purpose.
-
Every fix verified or undone
A scenario counts as handled only when Nightshift’s fix was applied, its check passed and the symptom was gone. A fix that does not hold is undone, and counted as a miss.
-
The last full run: 60 scenarios, 2 November 2026
Every scenario ran with nobody approving. Nightshift fixed and verified 15 on its own. It held 26 fixes for a person, and once a person approved them, all 26 were applied and verified, none undone. The other 19 needed a person with nothing to apply: refusals for the right reason, causes outside the cluster, and readiness work a person files.
-
What it missed
Two scenarios failed. A Service with no endpoints was never alerted on, because the sweep read only the first 25 Services. And a restart was proposed where nothing should change, argued from a past incident that recorded no fix. Both are fixed, and both passed when re-run on the release build. Still open: when Nightshift hands a fix to a person, its written steps named the exact change in 8 of the 14 scenarios that check them. That is the next piece of work.
Two agents, on purpose
The AI never gets your keys.
A coding agent reads the internet and then acts. Give it cluster credentials and a poisoned README becomes a production incident. So we split the job in two.
- WriteThe coding agent builds and tests its own work
- CheckCIS and Pod Security policy; findings go back to the agent
- Dry runAgainst your cluster’s own API server
- ApproveA human, unless you said otherwise
- DeployOur in-cluster agent — the only thing holding credentials
It only reaches one namespace
You open a namespace to coding agents. Nothing is open by default. The token expires, has a daily cap, and stops working the moment you close that namespace — no revocation needed.
Inside it, coding agents and AI assistants query metrics, logs, traces, dashboards and alerts through Seylo’s MCP server. They can propose a dashboard or a scrape-annotation change, and a person approves it.
Checked before it runs
Every generated change is checked against CIS and Pod Security policy and dry-run against your cluster. Findings go back to the agent to fix and re-check. Critical and high findings block, with no override. Config and environment values that look like credentials are refused, and never repeated back.
Never at this door
- Secret values.
- A second namespace.
- An approval it granted itself.
Not disabled — absent. The tools that would do these things do not exist, so no prompt can reach them.
In a namespace you open, it ships within limits you set; everywhere else, a person approves. Bring Claude Code or any MCP client, or use Seylo’s hosted coding agent as it is switched on — the deploy path is the same, and seylo-mcp is included in the platform fee.
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 in a row and a tenant-wide kill switch.
-
No cloud keys. No shell.
The agent connects outbound, and Seylo stores no cloud key at all; a cloud account is a read-only role you grant and revoke. There is no shell or attach into your containers at any setting. On a cluster you opt in, both sides, Nightshift may run a fixed list of read-only commands.
-
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
Toward a senior SRE, one verified fix at a time.
-
Deploy live
Controlled deployment
Releases, approvals, read-back, rollback, ownership refusal for Argo CD, Flux and Helm, audit, SSO. seylo-mcp for your coding agent.
-
Monitor live
Observability in your cluster
Metrics, logs, traces and APM, dashboards, uptime, alerts and notification channels, with the data on your disks. Cost computed in your cluster.
-
Act now
Nightshift and incidents
The AI SRE that starts on the alert, cites its evidence, and verifies every fix or undoes it. Incidents rooted at the cause on the service map, with one fix on the root. FinOps dashboards.
-
Build live
The hosted coding agent
Works on your repository in an isolated sandbox, runs the tests, and opens the pull request as you. A seat per person, paid before use.
-
Next
More of Kubernetes, more of it on its own
Nightshift's classes of fix grow one at a time. Each kind of failure is claimed only once Nightshift handles it in the failure zoo, and runs unattended only where your organisation has let it.
-
Next
Whole-cloud spend
Cost dashboards that add your whole cloud bill to your clusters’ cost, read in your own cluster.
-
Coming
Repo to running
Connect a repository. Seylo writes the infrastructure as code you own, your pipeline builds it in your cloud, and Seylo deploys it and keeps it running.
Pricing
Pay for what Seylo manages, for the fixes that worked, and for the people who build.
Seylo is paid from the first day, and your measured usage is shown to you in the product from that day on. One platform fee on the CPU Seylo manages — no charge per person, no limit on people. Nightshift is paid for by the fix that verified, not by the attempt. The coding agent is a seat per person, paid before use. Want to try it first? Write to us and we may grant your organisation a 30-day free trial of the platform and Nightshift; it does not cover coding agent seats.
$5 per managed vCPU / month
The only platform charge
- Managed vCPU is the CPU your pods request in the namespaces Seylo manages — not the size of your nodes
- An average across the month, not a peak, so a burst or a CronJob does not set the bill
- A first or last partial month is charged for the days it covers
- No charge per person and no limit on people
- seylo-mcp is included, deploying into your cluster through it as well
Metered and shown to you in the product from the first day, so you can check the vCPU figure we bill against at any time.
$6 per verified fix, after the first 5 free
Pay for the fix that worked
- A verified fix is a change Nightshift applied that passed its check and was not undone
- The price includes Seylo’s model tokens for Nightshift’s investigations
- A fix that did not hold, and a proposal nobody approved, are not charged
- The first 5 verified fixes are free, once per organisation
Nightshift investigations on your own model key are never billed by Seylo: your provider bills those tokens.
$20 per seat / month, paid before use
A seat for each person who builds
- An organisation admin buys seats for named people; a seat starts working once the payment is confirmed
- A seat covers the calendar month (UTC) it is bought for and is not prorated: bought on the 20th, it is still $20 and ends at the month’s end
- Renewal for the next month opens on the 25th; a seat not renewed stops at 00:00 UTC on the 1st until it is paid
- Each seat includes sandbox minutes and $5 of Seylo’s model (GLM-5.3) use per month; the model menu in the composer shows each model’s cost as a multiple (×)
- When the included use is spent, switch to your organisation’s own model key from the same menu. Top-ups are not available yet
- On Seylo’s model, one call is limited to 200,000 tokens of context and 32,768 of output
Tokens on your own key are billed by your provider, never by Seylo.
-
What a managed vCPU is
The CPU requests of running and pending pods in the namespaces Seylo manages, taken as a daily 24-hour average and then the mean across the month. Finished pods are not counted, and neither are containers with no CPU request. It is measured from kube-state-metrics, which the seylo-observability chart installs, and you can check it yourself with kubectl: the sum of CPU requests.
-
Included in the platform fee
Deployments, approvals and the audit trail; single sign-on; metrics, logs, traces, APM, dashboards and alerts; incidents and the service map; cost, chargeback and FinOps dashboards; seylo-mcp, the door your coding agent comes in by, deploys included. Observability data stays in your own cluster, on your own cloud bill, which is why there is no per-GB price. Right-sizing lowers the vCPU you request, so it lowers our fee too.
-
Not priced yet
GPUs are not measured or priced yet. Coding agent sandbox minutes beyond those a seat includes have no price yet. Nothing is charged for either until it has one, and it will be published here first.
Prices in USD, excluding any applicable tax. Invoiced by Seylo Labs Private Limited on the 1st of each month for the month before, and paid through Razorpay; a coding agent seat payment gets its own invoice, already marked paid. With an Indian billing address you are invoiced in Indian rupees at Seylo’s fixed rate of ₹97 per US dollar, printed on the invoice. How each line is measured: plans and billing. No bill goes up without notice. From 200 managed vCPU, ask us for volume rates on annual terms, quoted against what you actually ran.
Anyone can write the code now.
Shipping it, and keeping it running, is the hard part.
Open from 8 November 2026
Connect a cluster. Tell us the truth.
Paid from the first day, with your measured usage shown to you in the product from that day on. Want to try it first? Write to us, and we may grant your organisation a 30-day free trial of the platform and Nightshift. Teams with a real on-call rota and a real change-control process: ask us about a design partnership, and you get our attention as well as the product.