Frequently asked questions

It scans the images your cluster runs for vulnerabilities, verifies their signatures and attestations, decides what the admission webhook accepts, and keeps an audit record of every decision, exception and break-glass. The operator, its API, its console and its database are installed into a namespace you own.

It is not a runtime sensor. It does not watch syscalls, network flows or process trees inside a running container, and it will not tell you that a pod started behaving oddly at three in the morning. It is not a cloud posture tool either — it does not read your cloud provider account or your IAM policies.

What it does is narrower and provable: it decides what is allowed to start, and it keeps the record of what it decided.

For image security it overlaps with them, and it goes further: those engines can express "deny the :latest tag", but they have no scanner, no CVE cache and no signature verifier behind the rule. Kapan carries all three, and enforces the image-related rules from the same verdict store it scans into.

For everything else a policy engine does — labels, resource limits, namespace conventions — they remain the right tool, and the two run side by side without conflict.

Not in this release. Each cluster runs its own operator with its own database and its own console, and they are independent by design — which is exactly why nothing has to cross a cluster boundary. A fleet view that summarises many installations on one page is on the roadmap, without a date attached — we would rather say that than name a release we might miss.

The operator itself does — the release image is built and signed for both. Scan verdicts, however, are currently recorded against linux/amd64, so on a multi-architecture image the finding describes the amd64 child of the index rather than the variant an arm64 node will run. Per-platform verdicts are on the list.

Any conformant distribution from 1.27 onwards, including managed services, k3s and OpenShift. The operator uses standard admission webhooks and CRDs; it needs no node agent, no privileged DaemonSet and no kernel module.

Three values, once a day, for licensing: the licence identifier, a fingerprint of the cluster, and the operator version. Nothing else, and nothing that describes what you run — no image names, no findings, no CVE identifiers, no workload or namespace names, no cluster topology, no user accounts, nothing from your database.

It is not that we choose not to send those; there is no path that would carry them. The limits your plan sets on images and frameworks are counted and enforced by the operator inside your own cluster, so the counts have no reason to leave it. We hold no copy of your findings, your image names or your cluster's shape, and a security console that needs a list of every image you run is exactly the thing this product is built not to be.

Why the daily check exists at all, and what happens when it fails, is on the licensing page.

None. The daily licence check is not analytics and does not double as any: it carries the three values listed above and returns a verdict, and no part of it describes how you use the product. Nobody here can tell how many images you scanned, which frameworks you opened or whether anyone logged in this week.

The website has none either — no analytics script, no tag manager, no third-party embed — which is why the cookie notice has so little to ask about.

In a PostgreSQL database you control, inside your own namespace or on your own server. Export it, back it up, or drop the namespace — we cannot read it and we hold no copy.

The installation's name, the image reference and the verdict — never a node name, an internal address or an endpoint. Notifications go to the channels you configure (Slack, Teams, e-mail, webhook), and to nothing else.

No, and we would rather say so than sell you something that will surprise you in a month. Every installation is licensed, including Community Edition, and every licence is checked with us once a day. A cluster with no route out cannot do that, and there is no setting that turns the check off — one that could be turned off would not be enforcement.

Everything else about a disconnected installation does work as documented: the scanner and the signature verifier are pinned into the release image, and you mirror the vulnerability database into your own registry. What the operator needs is a route to the licence endpoint, not to the internet at large, and it can be a single allowed destination through a proxy.

If a genuinely isolated network is a requirement for you, write to kapan@portiger.com and say so plainly rather than discovering the answer at install time.

The Helm chart brings its own PostgreSQL, or takes a DSN to one you already run. Either way the operator creates and migrates its own tables on first start — there is no SQL for you to run and no migration step to forget on upgrade.

By default the webhook failure policy is Ignore: if the operator cannot answer, deployments proceed unguarded rather than stopping. That is the safe default for a cluster you have to keep running. Enterprise installations can set Fail and deny anything not yet scanned — a deliberate trade, made explicitly.

Admission is replicated and spread across nodes. Periodic work — scanning, licence checks, retention — is held by exactly one replica at a time through a PostgreSQL advisory lock, so a second replica never duplicates a scan or a notification.

The operator does. The pair is generated and rotated in-cluster, and every replica picks up a new one without a restart. There is no cert-manager dependency and no annual reminder in your calendar.

Upgrade is helm upgrade; embedded migrations apply the new steps and skip the rest. Uninstall is helm uninstall plus dropping the namespace. The webhook is removed with the release, so an uninstalled operator never leaves admission blocking behind it.

You create an account at customer.portiger.com, choose a package and any add-ons, and get a key. You enter that key in your own console, and the activation exchanges it for a signed certificate carrying what you bought, the cluster it was issued for and the date it runs to. Community Edition works the same way; its certificate simply has no expiry.

From then on the operator checks the certificate at every start without leaving the cluster — our signature, the expiry, and whether the fingerprint inside it is this cluster's. Separately, once a day, it checks the licence with us. The certificate is good for thirty days, so that daily check failing changes nothing for a long while; the licensing page has the whole of it.

The installation falls back to Community Edition. It does not stop, it does not lock you out, and it does not start denying deployments — scanning and admission carry on under the free limits. A security control that switches itself off over a billing date is a worse outcome than an unpaid invoice.

A certificate that lapses because the licence server has been unreachable for a month behaves the same way, and is announced well before it happens: the console warns after a week without a route and the administrators are e-mailed before the certificate runs out.

The trial is the full Enterprise feature set. Payment details are taken at signup and the first charge falls on day 31 — cancel before then and nothing is billed. When a trial ends without a purchase the installation falls back to Community Edition rather than shutting anything off.

Payments are handled by Paddle, acting as merchant of record. They issue the invoice and handle VAT in your jurisdiction, and we never see a card number. Enterprise purchases can be invoiced through your procurement process instead.

Up to the number your plan pays for, yes — that is what the cluster count on the price list is. Community and Team buy one, Business three, Enterprise as many as you need. The same key activates each of them and every activation spends one slot; your account shows which clusters hold slots and how many are free.

Beyond that number the next activation is refused rather than quietly allowed. You can release a slot you are not using, or add clusters to the key you already own without touching the installations already running.

Nothing changes for between ten days and a month, depending on how much life the certificate had left when the connection went. Failed checks are retried a few hours later rather than the next day, so an outage has to be sustained for weeks before it becomes a licensing problem — and the console warns after the first week rather than letting you find out later.

Being unreachable and being refused are different: silence spends the certificate's remaining life, while an answer saying the licence was released or revoked is applied at once.

Reinstalling the operator is free — the fingerprint is derived from the cluster, not from the operator, so deleting and redeploying it needs nothing from us and the certificate keeps working.

Rebuilding the cluster makes a new fingerprint, which is a new cluster as far as the licence is concerned, so it takes a slot. If you still have the old cluster, deactivate there first and the slot is free immediately. If it is already gone, release its slot from your account — the entry lists each cluster holding one and when it was activated, so you can tell which is which.

The current set covers Regulation (EU) 2024/2847 (the Cyber Resilience Act) and NIS2, with the control mapping shipped in the operator rather than fetched. The free edition includes one framework of your choice; paid plans carry more.

No, and it says so on the document. It is evidence produced from your own records, and no auditor is obliged to accept it. What it does is remove the spreadsheet stage: the record of who accepted which risk, when, and for how long is already written down.

met, partial, gap and outside_scope. A pass/fail report forces every control into a lie; outside_scope says a control does not apply to a Kubernetes admission controller, which is a defensible answer and a different one from failing. If the webhook was down for forty minutes on a Tuesday, that window is in the document.

In the public issue tracker at github.com/portiger/kapan-k8s. Reports from every edition are handled there in the open, including from Community Edition — the free tier is where most first reports come from, and closing them privately would waste that.

Not in a public issue. Use the private advisory path described on the security page, and you will get an acknowledgement within three working days. Fixed issues are published as advisories on the same repository once a release carrying the fix is out.

Community Edition is supported through the public issue tracker, which is also where paid editions' bugs are handled — reports are not sorted by what you paid. Paid plans add e-mail support, and from Business up your mail is handled before the queue. Enterprise support terms are whatever the agreement says, because that is a conversation rather than a line on a price list.

We do not publish a response-time guarantee for the plans below Enterprise. A number on this page would be a promise made to everyone at once by a team that has not agreed to it with anyone in particular, and we would rather answer quickly than write down a figure we might have to defend on a bad week.