Data collection, storage and retention
What KubeOn reads, what it never reads, where each kind of data is stored for each hub option, how it is encrypted, and how long it is kept.
On this page
What the agent and hub read
- Node names, instance types, capacity, zones and provider IDs
- Namespace, workload and pod names, labels and owner references
- CPU and memory requests and measured usage per pod
- PersistentVolume and PVC sizes, classes and status
- Service types and load balancer hostnames
- Billing line items from your export: cost, usage type and resource ID
What they never collect
- Secrets, ConfigMaps or environment variables
- Container images, logs or application data
- Request payloads or network packet contents
- Credentials of any kind from your clusters
- Personal data about your customers
The agent's ClusterRole grants no access to Secrets or ConfigMaps. The exact rules are in security and permissions.
Where data is stored
| KubeOn Cloud | Self-hosted in your cloud | On-premises | |
|---|---|---|---|
| Snapshots | HTTPS ingest in your workspace's region | Your bucket | An S3-compatible store or HTTPS in your network |
| Billing rows, allocations and reports | Your workspace's region: the US, the EU or the region you choose | Your account | Your network |
| Encryption keys | KubeOn-managed | Your KMS key | Your KMS or HSM |
| Who operates the hub | KubeOn | You | You |
For EU residency, choose the EU region when the workspace is created. See data sovereignty.
Encryption
- In transit: snapshot uploads, billing reads, the REST API, sign-in and gateway traffic use HTTPS. Email uses STARTTLS, and a self-hosted gateway connects to Redis over TLS.
- At rest on a self-hosted AWS hub: one customer-managed KMS key with rotation encrypts the database, cache, snapshot and results buckets, secrets and logs. Snapshots are uploaded with SSE-KMS.
- Integration credentials are encrypted before they are stored. A self-hosted hub refuses to start outside development without KMS configured.
How long data is kept
| Data | Kept | After that | Setting |
|---|---|---|---|
| Cluster snapshots | 14 days | Deleted by the snapshot bucket's lifecycle rule. Until then, a failed ingestion can be retried. | – |
| Pod usage samples | 30 days | Deleted. Container rightsizing reads the last 7 days and node sizing the last 14. | METRICS_RETENTION_DAYS |
| Billing rows | 90 days | Deleted from the hub. The costs allocated from them stay, and your export remains the record: a billing backfill re-reads up to 366 days of it. | COST_DATA_RETENTION_DAYS |
| Athena query results (AWS) | 14 days | Deleted. | – |
| Allocated costs and reports | Life of the workspace | Kept after the raw rows are gone. Late data is repaired automatically for the last 7 days. Admins and platform engineers can re-run allocation up to 92 days back from Data health; a day whose billing rows have left the hub (after 90 days by default) needs a billing backfill first. | – |
| Assistant usage ledger | 365 days | Deleted. | USAGE_RETENTION_DAYS |
| Request metadata | 90 days by default | Deleted. | – |
| Prompt and response bodies | Not logged by default | Written to the log only on routes where you turn logging on. Cached responses are covered in the next row. | – |
| Cached responses | Until the route's cache TTL ends | Expire with the TTL. | – |
| At your model provider | Set by your provider account | Requests go to your own provider account, so its data retention terms apply. | – |
Settings apply to self-hosted hubs. On KubeOn Cloud the same defaults apply and can be changed for your workspace.
Deleting data
- Self-hosted and on-premises hubs: the data is in your account or network, so you delete it on your own schedule.
- KubeOn Cloud evaluations: whether data is deleted or kept when the evaluation ends is agreed before it starts.
- Removing KubeOn step by step, including cloud access and snapshots: see remove KubeOn.
- Requests about personal data, such as user accounts: email privacy@kubeon.io.
Need help with this guide?Contact support