Privacy Policy
1. The one-paragraph summary
KubeManta is self-hosted. It runs inside your Kubernetes cluster, on your infrastructure. We do not receive your cluster's data — not your workloads, logs, metrics, configuration or secrets. What we collect is limited to the things any software vendor needs: who you are (email, name), that you paid (via Paddle, who holds your card details — we never see them), and that your license is valid (a license key and an anonymous cluster identifier). There is one important exception involving AI providers you choose to configure, and we describe it plainly in §5 rather than burying it.
Controller: Infrastratus, a sole proprietorship registered in the Republic of the Philippines (full registered address available on request and stated on invoices), registration number Contact: [email protected].
2. What this policy covers
| Covered | Not covered |
|---|---|
| The kubemanta.com website and its signup, contact and checkout flows | Your own cluster's data (you control it — see §5) |
| Our billing and licensing services (api.kubemanta.com, Keygen) | Third-party sites we link to |
| Our image registry (registry.kubemanta.com) | An AI provider you configure (their policy applies — §5) |
| Our support correspondence |
3. What we collect — the complete list
We collect only the categories below. Nothing else.
3.1 Free signup
When you request a free license key on the website, we collect:
| Data | Why | Where it goes |
|---|---|---|
| Email address | To send you your license key; to deduplicate repeat signups | Our leads database; Keygen; Resend (email delivery) |
| Name (optional) | To address you properly in the email | Same as above |
Marketing attribution — utm_source, utm_medium, utm_campaign |
To understand which channels bring people to us | Our leads database only |
| Referrer — the page you arrived from | Same | Our leads database only |
The marketing-attribution and referrer fields are captured by the website at page load and submitted with the form. We are stating this explicitly because it is not obvious from the form itself, which visibly asks only for an email and name.
3.2 Purchase
When you buy a subscription:
| Data | Who holds it |
|---|---|
| Payment card details | Paddle only. We never receive, see or store them. |
| Name, email, billing address, country, tax ID | Paddle (as Merchant of Record); we receive the name and email associated with the subscription |
| Subscription status, billing period, amounts | Paddle; we receive lifecycle events by webhook |
3.3 License validation (from inside your cluster)
This is the only data that flows from your cluster to a service on our side, and it is deliberately minimal. The installed Software contacts Keygen (our licensing provider):
| Transmitted | What it is |
|---|---|
| License key | The key you were issued. It is the credential. |
| Cluster fingerprint | The metadata.uid of your cluster's kube-system namespace — a random UUID that Kubernetes generated when the cluster was created. |
| A node count | How many nodes your cluster is running. This is product telemetry, not billing data: our pricing is per paid admin seat (Terms §5.3), there is no node limit and no per-node charge, and no charge is ever calculated from these figures. We use them to understand the cluster sizes the product runs at and to support you. The exact fields are listed below. |
The node count is sent as eight numbers and nothing else:
| Field | What it is |
|---|---|
nodes |
How many nodes the cluster had at the moment of the report. |
nodes_avg |
The average node count across the current calendar month. |
nodes_avg_samples |
How many readings that average is based on, so a thin sample is not mistaken for a month of evidence. |
nodes_peak |
The highest the count reached during the month. |
peak_month |
Which calendar month these figures cover, as YYYY-MM. |
nodes_term_peak |
The highest the count has reached during the current license term. |
term_started_at |
When that license term began (a timestamp). |
reported_at |
When the reading was taken (a timestamp). |
That is the entire payload. Specifically, we want to be unambiguous about what is not sent:
- ❌ No node names, labels, instance types, zones, or regions — only how many
- ❌ No pod counts or workload counts
- ❌ No workload, namespace, image, or resource names
- ❌ No logs, metrics, events, or configuration
- ❌ No user names, email addresses, or IP addresses in the payload
- ❌ No cluster name or cloud provider
The fingerprint is a random UUID. It identifies that this is the same cluster as last time; it tells us nothing about the cluster. We use it solely to enforce one-license-per-cluster and to free the seat when a cluster goes away.
Frequency: full validation every 12 hours; heartbeat every 6 hours (both configurable). The node count travels with the heartbeat rather than on a schedule of its own, at most once a day, and only when the figure has actually changed — a cluster with a stable node count sends it once and then stops. If our license service is unreachable, the Software works from its cached entitlement for 7 days before degrading to Free tier.
Measuring is not billing. Nothing in the Software raises a charge, and no charge exists that these figures could feed: pricing is per paid admin seat, and the Software counts seats by your own user-account assignments, not by anything in this payload. Nothing about your cluster's size can change what you pay.
You can turn the node count off by setting LICENSE_METER_ENABLED=false.
License validation and the heartbeat continue as normal, no feature is affected,
and the count is still calculated and shown to you in Admin → License.
Air-gapped installs, and any cluster whose license is not currently valid, send
nothing either way.
Honest note on air-gapped installs. Some of our documentation has described air-gapped license verification as fully offline. As of this document version that is not accurate for the shipped code: the Software still attempts the Keygen call in every mode. In an air-gapped install the call is simply blocked at the network layer, and the install runs on its cached entitlement for the 7-day offline grace period. We are correcting the affected documentation. If genuinely offline license verification matters to you, contact [email protected] before purchasing.
3.4 Version / update check (from inside your cluster)
The Software can check whether a newer version exists, by making a plain
GET https://api.kubemanta.com/version.
This request sends nothing about you or your cluster — no body, no query parameters, no license key, no fingerprint, no identifying headers. It is a bare request for a public version file, cached for about 6 hours. Our server sees only the network-level source IP address, as any web server would.
It can be turned off entirely: in the product (Admin → License), by Helm value
(updates.checkEnabled=false), or by environment variable. It is off
automatically in air-gapped mode.
3.5 Website analytics
We use Umami, self-hosted by us at analytics.kubemanta.com. It is cookieless — no tracking cookies, no cross-site tracking, no advertising identifiers, no data sold or shared with anyone. We do not use Google Analytics or any third-party advertising tracker.
It records aggregate page views, referrers, and a small number of product events (clicking the free-install CTA, submitting the signup form, copying the install command, starting checkout).
3.6 Support and contact
If you email us or use the website contact form, we collect your name, email address and whatever you put in the message. The contact form is delivered to our support mailbox via Resend.
3.7 What we deliberately do not collect
- ❌ No product telemetry beyond one number. The Software does not phone home with feature-adoption metrics, error reports, crash dumps, or performance statistics. The single exception is the node count described in §3.3 — a size figure only, never used to calculate a charge, never describing your workloads, and one you can switch off.
- ❌ No tracking cookies on the website.
- ❌ No advertising or data-broker sharing. We do not sell personal data, and we do not "share" it for cross-context behavioral advertising as CCPA/CPRA uses that term.
4. Payments — Paddle is the Merchant of Record
Paddle is our Merchant of Record. Paddle is the seller of record for your transaction and handles payment processing, invoicing and global tax.
Paddle holds your card details. We do not. We never receive a card number, and there is no card data in any system we operate. From Paddle we receive only subscription lifecycle information (activated, renewed, cancelled, refunded) and the associated name and email, so we can issue and manage your license.
Paddle processes your data as an independent controller for its own payment and tax obligations. See Paddle's own privacy notice, and our Subprocessor List.
5. AI providers — the important nuance, stated plainly
This is the part that deserves care, and we would rather over-explain it than let you discover it later.
5.1 By default, nothing leaves your cluster
Out of the box, KubeManta's AI features are not connected to any external provider. No cluster data goes anywhere.
5.2 If you configure a third-party AI provider, prompt content leaves your cluster — to them, not to us
If an administrator in your organization configures a third-party AI provider (such as Anthropic or OpenAI) with your own API key, then when someone uses an AI feature:
- The prompt — which may include cluster context such as namespace and pod names, Kubernetes events, resource specifications, and redacted log excerpts — is sent from your cluster directly to that provider.
- It goes under your own account, subject to that provider's terms and privacy policy.
- It does not pass through us. We never see it. There is no relay, no proxy, and no copy on our side.
You — not we — are the controller of that transfer, and you should satisfy yourself that your chosen provider's terms are acceptable for your data.
5.3 The controls we give you
We built the controls to make this governable, and they are real, enforced mechanisms rather than settings that only affect a display:
| Control | What it does |
|---|---|
| Local-only mode | Restricts AI to an allowlist of providers. Configured for a locally-run model (such as Ollama in your own cluster), no prompt data leaves your network at all. |
| Outbound domain allowlist | Deny-by-default list of hosts AI traffic may reach. A blocked attempt is refused and written to your audit log. |
| Secret redaction | Pod logs are scrubbed for credential-shaped content before they are placed in any prompt (see §5.4). |
| Namespace scoping | Restrict which namespaces AI features may read at all. |
| Master kill switch | One administrator setting disables every AI entry point. Everything else in the product keeps working. |
| Prompt audit log | Optionally record every prompt and response, in your own cluster, for compliance review. |
5.4 What redaction does and does not do — precisely
Before pod logs reach any AI prompt, the Software scrubs them for
credential-shaped content: values following keywords such as password, secret,
token, api_key, auth and bearer; long base64-encoded blobs; and
recognisable API-key formats such as OpenAI (sk-…) and GitHub (ghp_…) tokens.
Administrators can add their own patterns.
Two honest limitations:
- Redaction is a pattern matcher, not a guarantee. A secret that does not look like any of these patterns can pass through. Treat it as strong risk reduction, not as proof that no secret can ever reach a provider.
- Redaction applies to log text and recorded command detail — not to structure. Namespace names, workload names, image names, labels, environment variable names, and resource specifications are not redacted and can reach a provider you have configured. If those names are themselves sensitive in your environment, use local-only mode.
- Redaction can be switched off by an administrator in your own organization. It is on by default. We state this because claiming unconditional redaction would be false.
5.5 Bring-your-own model
You can run a local model (for example Ollama) inside your own cluster and point KubeManta at it. In that configuration AI features work with zero external egress of prompt content. For regulated and air-gapped environments this is the configuration we recommend.
6. Why we are allowed to process this (lawful bases)
For users in the EU/UK, under GDPR/UK GDPR Article 6:
| Processing | Lawful basis |
|---|---|
| Issuing a free license key; delivering it by email | Contract — you asked for it |
| Billing, subscription management, license validation | Contract — performing our agreement with you |
| Node-count telemetry (§3.3) | Legitimate interests — understanding the cluster sizes the product runs at and supporting you; counts only, disableable, and never used to calculate a charge |
| Marketing attribution (UTM, referrer) and website analytics | Legitimate interests — understanding how people find us, using cookieless analytics with minimal privacy impact |
| Responding to support and contact messages | Legitimate interests / Contract |
| Retaining billing and tax records | Legal obligation |
| Security, fraud prevention, license-abuse prevention | Legitimate interests |
Where we rely on legitimate interests we have considered your rights and concluded, given the minimal and non-intrusive nature of the data, that they are not overridden. You may object at any time (§10).
Consent. When you sign up or purchase, we ask you to agree to the Terms of Service and this Privacy Policy via a single unticked checkbox that you must actively tick. We record the timestamp and the document version you agreed to, so it is always determinable exactly what you accepted. See WEBSITE_INTEGRATION.md.
7. How long we keep things
| Data | Retention |
|---|---|
| Lead record (email, name, UTM, referrer) | Until you ask us to delete it, or 24 months after last contact, whichever is sooner |
| License records (key, fingerprint, tier, status) | For the life of the license plus 24 months, for entitlement and dispute handling |
| Billing and tax records | As required by tax law in the Republic of the Philippines — typically several years; held primarily by Paddle |
| Website analytics | Aggregate, cookieless; 24 months |
| Support correspondence | 24 months |
Data in your cluster is not on this table, because we do not hold it. Its retention is configured by you, in your own installation. The Software's internal retention defaults (audit log, activity feed, scan history and so on) are documented for your administrators in the project's data-retention documentation and are entirely under your control.
8. Who we share data with
Only the service providers required to run the business. Each is listed, with the data it receives and why, in the Subprocessor List — Paddle (payments), Keygen (licensing), Resend (transactional email), Zoho (our mailboxes), Cloudflare (DNS and network), plus our own infrastructure.
We also disclose data if legally required (court order, lawful request), or to establish or defend legal claims. If we are ever compelled to disclose your data we will tell you unless legally prohibited.
We do not sell your personal data, and never have.
9. International transfers
We operate from the Republic of the Philippines. Our providers operate internationally, so your data may be processed outside your country — including in the United States and the European Union.
10. Your rights
Depending on where you live, you may have the right to:
- Access the personal data we hold about you
- Correct it if it is wrong
- Delete it ("right to erasure")
- Port it — receive it in a machine-readable format
- Object to processing based on legitimate interests, including any marketing
- Restrict processing while a dispute is resolved
- Withdraw consent where we relied on it
- Not be subject to solely automated decision-making with legal effects — we do not do this
How to exercise them: email [email protected] from the address you signed up with, describing what you want. We respond within 30 days. We do not charge for this.
Because we hold so little, most requests are quick to satisfy: for the majority of users the entire record is a lead row (email, name, attribution) and a license record.
Complaints. If you think we have handled your data improperly, please tell us first — we would rather fix it. You also have the right to complain to your data protection authority: in the EU, your national DPA; in the UK, the Information Commissioner's Office.
California (CCPA/CPRA). California residents have rights to know, delete, correct, and opt out of sale/sharing. We do not sell or share personal data, so there is nothing to opt out of. We will not discriminate against you for exercising a right. Use the same contact address above.
11. Children
KubeManta is a business tool, not directed at children, and we do not knowingly collect data from anyone under 16. If you believe a child has given us data, email [email protected] and we will delete it.
12. Security
Measures protecting the data we hold include encryption in transit, encryption at rest for credential material, access controls limiting access to those who need it, and encrypted off-site backups whose decryption key is stored offline.
The Software's own security architecture — the part running in your cluster — is described in Security & Trust, including an honest account of what we have not yet done (we hold no SOC 2 certification and have not yet commissioned a third-party penetration test).
To report a vulnerability: [email protected].
13. Changes to this policy
We may update this policy. The document version at the top changes each time. For material changes affecting how we use your data, we will notify you by email and/or a prominent website notice before they take effect.
Because each consent is recorded against a document version, it is always determinable which version you agreed to.
14. Contact
| Purpose | Contact |
|---|---|
| Privacy questions, data-subject requests | [email protected] |
| Security vulnerabilities | [email protected] |
| Everything else | [email protected] |
Infrastratus · a sole proprietorship registered in the Republic of the Philippines (full registered address available on request and stated on invoices) ·
Related: Terms of Service · EULA · DPA · Subprocessors · Security & Trust