Honest answers,
no softening.

Docker Hub stores images. It does not verify them, doesn't tell you what's in them, and doesn't tell you who built them. The consequence: every docker pull nginx is a leap of faith — into a bytestring written by someone you've never met, with no cryptographic record of how it got there.

Flareo rebuilds every module from source in a hermetic environment, generates a CycloneDX SBOM, scans for CVEs, signs with cosign keyless, attests with SLSA provenance, and logs the signature to Rekor. Every claim has a receipt. The two services do different things; we don't compete on catalog size.

Detail at how Flareo compares.

Artifact Hub indexes existing Helm charts, operators, and OCI artifacts and shows their metadata. It doesn't build them, doesn't sign what it indexes, and doesn't let you try them. Flareo's pipeline is the difference: every Flareo module was built by us, in our environment, with our receipts.

Those platforms deploy software for you, on their infrastructure. That's a different shape from what Flareo does — Flareo gets you to a verified image and a portable docker-compose.yaml that runs on YOUR infrastructure. We don't host your deployment; we prepare it.

If you want managed hosting and don't mind the lock-in, those platforms are good. If you want the verification chain plus the freedom to run wherever, Flareo is the seam.

Coolify and Dokku are deployment runners — they help you run software on your own VPS. They don't help you choose what to run. Flareo helps you discover and verify; you point your existing Coolify (or Compose, or Kubernetes) setup at the resulting image. The two are complementary, not competitive.

A Flareo module marked Verified means all of these are true:

• Built in our hermetic BuildKit environment from declared source
• Scanned by Trivy with zero critical CVEs at scan time
• CycloneDX SBOM generated and bound to the image digest
• SLSA L1 provenance attestation produced and signed
• Image signed with cosign keyless, signature logged to Rekor
• Passed the policy gate (today: human reviewer using the gate's signals; tomorrow: automated OPA evaluation)

"Verified" is precise here, not marketing-precise. The definition appears in the Trust Score docs and on the threat model page. If a module loses any of these signals on a subsequent rebuild — e.g., a new CVE drops — the status flips and the catalog shows it.

You don't, fully. Verification establishes provenance and known vulnerability posture. It does not establish that the upstream code is benign in intent — a malicious upstream can produce a "verified" module by Flareo's standards.

What verification gives you is the ability to react fast when something is found. Because every module has an SBOM, the moment a CVE drops we know which modules are affected and can rebuild them. Because every signature is logged to Rekor, you can prove what version you ran. Because the canary chain rebuilds daily, your image is never more than 24h stale on upstream patches.

The honest framing: Flareo replaces "trust the publisher" with "verify the chain and respond fast." Both are weaker than "this code is provably safe" — which doesn't exist in software.

Currently, admin review is performed by the Flareo team — a small group, not a single person, with two-eye review for any new publisher and any module that touches authentication primitives. Decisions are logged to an internal audit table and surfaced on the module's detail page (date, decision, reviewer initials) so submitters can see exactly what happened to their submission.

The proposal-stage policy-as-code admission gate is intended to automate the parts of review that are mechanical (CVE counts, SBOM presence, signature). Human review will remain for the ambiguous calls (is the upstream legitimate? is this a repackaging of someone else's project?). See the roadmap for delivery date.

Yes — that's the entire design point. Every module's signature is in Rekor (a public, append-only transparency log we don't control). Every SBOM and provenance attestation is downloadable. Every claim Flareo makes about a module has a one-line command you can run on your own machine to check independently. See /verify for an in-browser version, or run cosign verify + trivy image + slsa-verifier locally with the snippets shown on every module page.

"Don't take our word for it" is the strongest trust signal we can offer.

When you click Preview, Flareo provisions a fresh Docker container in our execution plane, on a randomly-generated subdomain behind Caddy. We see what any operator of a hosting service sees:

• The container's stdout/stderr (visible in your dashboard for the session)
• The HTTP requests made to the container (because they pass through our reverse proxy)
• Resource consumption (CPU, memory, network) for billing and abuse detection

We do not introspect your traffic content beyond the URL path. We do not retain preview logs after the session ends. We do not retain any state from the preview container after the 30-minute timeout.

If you need to test something with sensitive data, run it locally with the takeaway artifacts — preview is for "does this thing work and look right," not for production trials.

At 30 minutes, the container is terminated and the subdomain is reclaimed. Any state in the container is destroyed. You'll get a 5-minute warning in the preview UI, with an "Extend 15 minutes" button — Pro users get one extension, Enterprise users get unlimited extensions in the same session.

Free-tier preview is intentionally ephemeral so we can offer it without authentication. Real evaluation happens after you take away the compose file.

Yes, by design. Flareo's value is verification at the time of publishing — once you've pulled an image and have its compose file, your deployment runs against the public registry (ghcr.io) and uses signatures logged to public Rekor. Both are independent of Flareo's continued operation.

If Flareo were to shut down:

• Existing pulled images keep working — they're in ghcr.io
• Existing signatures keep verifying — Rekor is public infrastructure
• Existing SBOMs and attestations remain downloadable from ghcr.io artifacts
• New rebuilds would stop — your deployed version becomes the frozen-at-shutdown version

We'd commit to publishing 6 months of advance notice and opening the canary rebuild infrastructure for community fork. Both commitments are concrete; if Flareo continues, they never fire, and they don't cost us anything to make.

The answer is "not yet, but it's a near-term roadmap item." The architecture (Control Plane + Execution Plane separation, standard open-source tooling, no proprietary services) is compatible with self-hosting. What's missing is the packaging work and the support story — we want it to be a real experience, not a "good luck" tarball.

Target: an Enterprise tier self-host bundle in 2026 Q4. See /roadmap.

Today: no. Flareo is exposure-only for submitters — your module is listed publicly, you're credited as the maintainer, and your publisher profile shows traction signals (deploys, reviews, rebuilds).

We've considered (and not yet committed to) revenue-share for the most-deployed modules on the Pro tier. The reasoning to hold off: it changes the supply-side incentives in ways we can't yet predict, and we'd rather see the catalog grow on voluntary contribution before introducing money. If we move, we'll publish the model in detail before activating it.

Full economic terms — including IP handling, attribution, and what publisher analytics you can see — are documented on /publish.

The canary chain catches it: when upstream stops cutting releases for > 90 days AND no security advisories have been addressed, the module's status flips to "upstream dormant" and a banner appears on its detail page warning consumers. Trust Score is unaffected — dormancy is not the same as insecurity — but the banner ensures consumers see it.

If upstream stops responding to a CRITICAL CVE for > 30 days, we fork-and-patch internally if the module is widely deployed; otherwise we delist with notice to consumers. Delisted modules are documented on /incidents.

We delist a module when any of these is true:

• The submitter requests removal (their module, their call — we honor this within 7 business days)
• A valid DMCA notice or trademark complaint is filed against the upstream code or our packaging of it
• A critical CVE remains unpatched in upstream for > 30 days (see above)
• The module is found to be malicious, repackaging non-attributed code, or otherwise violating our publisher guidelines

Takedowns are public — they appear on /incidents with the reason category. Submitters get 7 days to respond before public takedown except in the malicious-code case, where we delist immediately and notify after. Full process and appeals path on /publish.

Flareo doesn't retain submitter source code beyond what's needed to reproduce the build. Source archives are deleted 30 days after takedown except for what's required for legal audit (the SBOM, the attestation, the signature — these are receipts of what we did, and we keep them).

Built images we've published remain in ghcr.io until the public registry's retention period elapses. We don't proactively delete them; consumers can pin to a digest if they want continuity.