Firefly is the one comparison on this site where the core overlap is real, not a gap. It finds resources no Infrastructure-as-Code declares, across AWS, Azure, GCP and Kubernetes: the same category Cloudkeel-DD leads with. This page does not pretend that overlap away. It says where the two still diverge, and where Firefly is simply ahead.
Every claim about Firefly below is from their own pricing page, marketing site or product docs, linked at the bottom.
What actually overlaps
Firefly aggregates resources across connected cloud accounts and flags which ones are “codified” (in IaC) versus “unmanaged” (created by hand, never committed anywhere): their own term for the exact category we call unmanaged resources. It reads Kubernetes too, through an agent it runs inside your cluster that watches continuously and polls every 15 minutes by default, covering pods, deployments, services and more. Their docs do not enumerate a full kind list, so we are not claiming ours is broader; we are not claiming anything here at all beyond what their own page says.
It also attributes changes to a user. Firefly’s Event Center records an “Owner: the user or role responsible for the change” plus the source IP, for both console (ClickOps) and CLI/SDK events. We do the same thing a different way (native cloud audit logs, best-effort, within a lookback window), and we are not going to pretend theirs doesn’t exist just because it competes with a claim we lead with elsewhere on this site.
Where we actually differ
- Self-hosted versus SaaS. Firefly is SaaS only; nothing in their pricing page, marketing site or Kubernetes docs mentions an on-prem or self-hosted option. Cloudkeel-DD runs inside your own cluster under credentials you hold, at every tier.
- Read-only versus write. Firefly’s Essential tier includes “auto-remediation” and their marketing describes an “AI SRE” that fixes violating assets directly. Enterprise adds instant recovery and rollback: real infrastructure-control capability. Cloudkeel-DD never writes to your cloud; remediation is a pull request you review, always.
- Entry price. Firefly’s paid floor is $2,499/mo (Essential, billed annually, up to 20K assets), after a 14-day free trial with full feature access and no card required. Cloudkeel-DD has a Free tier and paid plans; see current pricing for scope limits and terms.
Where that leaves you
| Cloudkeel-DD | Firefly | |
|---|---|---|
| Unmanaged resource discovery | Yes: AWS, Azure, GCP | Yes: AWS, Azure, GCP, plus Kubernetes and SaaS providers |
| Kubernetes | Live cluster read: Helm, ArgoCD, Flux, sixteen kinds | Live cluster read via an in-cluster agent; kind list not enumerated in their docs |
| Change attribution (who made it) | Best-effort, all three clouds’ native audit logs, within a lookback window | Owner (user or role) + source IP, via their Event Center, documented as a first-class feature |
| Cloud write access | None: read-only, enforced in code | Auto-remediation, rollback, instant recovery (Enterprise) |
| Remediation | Reviewed pull request, never an unattended write | AI-driven auto-remediation, applied directly |
| Deployment | Self-hosted Helm chart, standalone | SaaS only; no self-hosted option found on any page read |
| Entry price | Not set: pilot stage | 14-day free trial, no card; Essential $2,499/mo (annual, ≤20K assets); Enterprise custom |
The difference that actually matters
Firefly can fix things. We cannot, on purpose.
A platform that auto-remediates needs credentials that can change your cloud, and once it has them, “AI SRE” and “instant recovery” are only as safe as that access is scoped and audited on their side, not yours. Cloudkeel-DD holds read-only credentials, in your own cluster, with the read-only guarantee enforced in code rather than promised in a policy document.
The cost is real and we said the same thing on the other two comparison pages: we cannot fix anything for you. If what you want is a platform that finds the problem and closes it in the same motion, Firefly does that today and we do not do it at all.
Where Firefly is ahead
Said plainly, because a comparison that only lists our wins is an advert.
- They already do unmanaged discovery, in production, across four cloud targets. This is the one page on this site where that is not a differentiator for us: it is the same category, and they shipped it first.
- Their attribution is a documented, first-class feature: an owner field and a source IP, not a best-effort fallback. Ours can fail silently if the IAM permission it needs is missing; nothing in Firefly’s docs suggests the same failure mode.
- They can act on what they find, including rollback and disaster recovery at the Enterprise tier. We only ever open a pull request.
- Public pricing and a real free trial: a 14-day trial with full feature access and no card. Cloudkeel-DD offers a Free tier and paid plans, with published scope limits and terms.
- They are an established, actively marketed product. We have no public customers and no SOC 2.
What we do not do
The limits, in the same breath as the claims:
- Unmanaged detection needs a Terraform state source. Something has to define “managed”. A cloud credential on its own produces nothing.
- Attribution is best-effort and can fail quietly. If the IAM permission it needs is missing, the actor is simply absent and nothing on screen says why.
- Kubernetes coverage is sixteen kinds, not arbitrary custom resources.
- Codify emits a Terraform
import{}block only, never a resource body. - No PDF export. CSV exists, is generated in the browser, and carries aggregate report metrics only; there is no per-finding export in any format.
- No cost governance and no pull-request-time gate.
- No rollback and no disaster recovery. If a resource is deleted, we can tell you it’s gone; we cannot bring it back.
- Scans are point-in-time, on a schedule you set. This is not a live feed and we will not describe it as one.
- Nothing phones home: no telemetry, no analytics, no licence server, and it runs air-gapped. But three paths do carry finding data outward when you configure them: notification webhooks, and the GitHub and GitLab integrations that open remediation pull requests. We will not tell you nothing leaves your environment, because that would not be true.
Which one to pick
Choose Firefly if you want a platform that finds ungoverned cloud resources and Kubernetes objects and can act on them directly, and you are comfortable with a SaaS vendor holding write-capable credentials to your estate.
Choose Cloudkeel-DD if you want the same category of finding (including resources no state file declares) without granting write access to anything, running entirely inside infrastructure you already control, and you would rather review every change yourself than let a platform apply it for you.
What about the clouds’ own tools?
Azure Policy, AWS Config and GCP Asset Inventory each answer part of this: inside their own cloud, in their own query language, without reference to your Terraform. If your estate is one cloud, evaluate them first; they are already paid for. If it spans clouds, the check becomes three different checks, and none of them can say “this resource is in no Terraform state”, because that comparison needs your state, which is the input they do not take.
Read more
- What Cloudkeel-DD is: the product page
- Exactly where the depth ends: coverage, generated from the engine
- Install it yourself: no call, no account
Sources
- Firefly pricing tiers, trial terms, Essential/Enterprise features: firefly.ai/pricing
- Firefly unmanaged/codified resource framing, auto-remediation, AI SRE: firefly.ai
- Firefly Kubernetes integration (live cluster, in-cluster agent, scan frequency): docs.firefly.ai/integrations/data-sources/kubernetes
- Firefly Event Center (owner and source-IP attribution): docs.firefly.ai/detailed-guides/event-center
Read 2026-08-23. If any of this has changed, tell us and we will correct it; a comparison that goes stale is worse than none.