Trust
Data handling
In short. Seylo keeps the record of your clusters — what is deployed, who changed it, and aggregate usage — so it can propose, approve and audit changes. It does not keep your Secret values, and it does not copy your raw metrics, logs or traces out of your cluster.
1. What stays in your cluster
- Kubernetes Secret values. Replaced with a placeholder by the agent before anything is sent, and stripped again by the server. Never stored, logged, returned or exported.
- Raw metrics, logs and traces collected by the observability chart (VictoriaMetrics, VictoriaLogs, VictoriaTraces, OpenTelemetry, kube-state-metrics). They are stored in your cluster, by default for 30 days, on your own infrastructure bill.
- Pod logs you view in Seylo are streamed to your browser, not stored.
- Shell access. There is none: no interactive shell, no attach. On a cluster you opt in (a chart value on your side and a switch in Seylo, both off by default), Nightshift may run a fixed list of read-only commands, and their output is redacted in your cluster.
2. What Seylo stores
| Data | Why |
|---|---|
| Cluster inventory: namespaces, workloads, image tags, and summaries of environment and ConfigMap settings | The fleet dashboard and version matrix |
| Manifest history for changes made through Seylo, with Secret values removed, in a hash-chained record | Diffs, rollback and audit |
| Aggregate CPU, memory and network usage per container per time window | Right-sizing, cost and the managed-vCPU figure you are billed on |
| Operations, approvals, alerts and their timelines, policy findings, cost proposals | The product’s core workflow |
| The audit trail | Who proposed, approved and changed what |
| Usage snapshots (managed vCPU, verified fixes) and billing details | Billing |
| Configuration: notification channels, routing rules, alert rules, identity-provider settings | Running the features you configure; their secrets are encrypted and write-only |
| Nightshift’s memory: one short lesson, at most 1,200 characters, per alert or incident it worked on — where, the symptom, the cause it found, the fix in one line, whether it held, and the numbers and kinds of the evidence. No Secret value, no log lines, no evidence text and no email addresses | So the next investigation can recall what happened before and which fix held. See Nightshift’s memory |
Personal data about the people who use Seylo is described on our PII handling page.
3. Queries and AI
- When you open a dashboard or a coding agent queries your telemetry, the result is fetched from your cluster for that request. Log lines are redacted on the way out.
- Nightshift investigates new alerts on its own once a model is set, and Seylo’s model is the default, so it is on unless an administrator chooses otherwise under Nightshift → Settings. The model receives a numbered evidence bundle built from your data, with redaction applied first. It goes to the provider your organisation chose: Seylo’s model (see sub-processors) or your own, under your own key.
Nightshift’s memory
- What it keeps. One short lesson for each alert and incident Nightshift worked on, as listed above. The same workload, alert, cause and fix within 30 days is one lesson with its counts going up. An investigation that found no cause is not remembered.
- Where. In your region’s Seylo database with the rest of your organisation’s data, and nowhere else. It is never shared with another organisation and never used to train a model; a lesson reaches a model only as evidence inside one of your own investigations, through the model your organisation chose.
- Who sees it. Only your organisation’s administrators, on Nightshift → Memory.
- How long. 365 days after a lesson last recurred, by default; an administrator can set 30 to 730 days. A shorter period deletes older lessons at once.
- Turning it off and deleting it. Memory is on by default. An administrator can turn it off (Nightshift stops storing and using lessons; nothing stored is deleted), delete one lesson or all of them, and export them as JSON. Each delete, export and change of setting is in the audit log, without the lesson’s text. When your organisation leaves Seylo, its memory is deleted with the rest of its data.
4. How long it is kept
| Data | Default retention |
|---|---|
| Operations history | 30 days |
| Alerts and their timelines | 30 days |
| Usage aggregates | Full detail for 2 days, then hourly for 14 days |
| Uptime check results | 30 days |
| Telemetry in your cluster (observability chart) | 30 days, set by you |
| Nightshift’s memory | 365 days after a lesson last recurred; 30 to 730, set by your administrators |
| Audit trail | Life of the organisation; not deleted automatically |
These are defaults; a deployment can be configured differently, and the table shows ours. When an organisation closes its account, we delete its data within 90 days of a written request from one of its administrators. We keep the audit trail, and the billing and tax records the law requires, only for as long as they are needed. Deletion is carried out by Seylo; it is not yet a self-service action.
5. Where it is stored
Seylo is hosted on Microsoft Azure in the United States. We may add a region in India. The database connection is encrypted, and stored credentials and secrets are additionally encrypted with AES-256-GCM. See our security page.
6. Getting your data out
Manifests managed through Seylo can be exported to your own Git repository. For anything else, email support@seylo.in.