SHIP YOUR
CONTAINER WITH
CRYPTOGRAPHIC RECEIPTS.

Your code stays yours. The license you publish under (MIT, Apache-2.0, AGPL-3.0, whatever you've declared in your repo) is the license that governs the source, the build outputs, and the published image. We don't require a CLA, a copyright assignment, or any transfer of rights to participate.

What we keep is the receipts. The CycloneDX SBOM, the SLSA provenance attestation, the cosign signature, the Trivy scan output, the policy decision log — these describe what we did during our pipeline run. They're ours because we made them, and they're part of the audit trail you'd want us to retain even after a takedown. Receipts are not your code; they're records about your code.

No exclusivity. You can also publish to Docker Hub, GHCR, Quay, your own registry, wherever. Flareo doesn't require nor reward exclusive listings. If your module is already on three other registries, that's fine.

Every module page lists the upstream maintainer (the original project author, e.g. vaultwarden/server for the vaultwarden image) and the Flareo publisher (the account that submitted it to our pipeline). Both names are clickable. If you're both — packaging your own project — both names are you, and you can choose to display only one via your publisher settings.

Publisher profile pages at /@your-username aggregate everything you've published, total deploys, total reviews received, and a short bio you control. The proposal language was “humans trust humans” — your name, your link, your face if you want it.

For repackagings: when you're submitting someone else's upstream (e.g. a hardened build of nginx), the upstream project gets the primary attribution and you get the “packaged by” subline. We don't pretend you authored what you packaged.

Free-tier publishers see, on their dashboard:

• Total registry pulls (lifetime + last 30 days)
• Total reviews received, with the public review text and rating
• Rebuild history (success / unchanged / failed, with timing)
• Reports filed against the module (you see them as the publisher does)
• Trust Score history over time

Pro-tier publishers additionally see geographic distribution of pulls, version-pinning patterns (which versions consumers stuck on), and inbound link analytics (how visitors are arriving at your module page).

What we don't track: we do not track individual consumer identities, IP addresses tied to pulls, or pull-time correlations across modules. The analytics we publish are aggregate signals you'd want as a maintainer, not surveillance of the people running your software.

Submitter-initiated: if you want your own module removed, the dashboard has a “Request takedown” button on the module's publisher page. Within 7 business days the module is delisted from the catalog and marketplace. The image stays in the public registry until ghcr.io's retention policy elapses (so consumers running pinned digests aren't broken) but new pulls are no longer surfaced through Flareo. Receipts (SBOM, provenance, signatures) remain available — they describe what was true at publish time and that history doesn't change.

Flareo-initiated: we delist a module when ANY of the following is true:

• A valid DMCA notice or trademark complaint applies to your upstream code or our packaging
• A critical CVE in upstream remains unpatched for > 30 days AND we can't fork-and-patch ourselves
• The module is found to be malicious — backdoor, data exfiltration, undocumented network behavior, license-laundered proprietary code
• The publisher has gone silent on multiple takedown-relevant emails for > 60 days when consumer-impacting issues need a response

Notice and appeal: in every case except the malicious-code one, you get 7 days of notice before public delisting and a written explanation of the specific reason. Appeals go to appeals@flareo.dev and reach a different reviewer than the one who made the original call. Malicious code skips the 7-day notice — we delist immediately and notify the publisher (and /incidents) within 24 hours.

The pipeline performance you can expect, by plan tier:

These numbers reflect actual median performance over the past 90 days, not aspirational targets. If we miss them on your submission, the dashboard tells you and we tell you. Pro and Enterprise customers who experience SLA misses get prorated credit per the terms.

The marketplace ranks modules by a deterministic combination of recent reviews, rebuild freshness, trust score, and deploy count. Editorial featuring is added on top of that ordering, but cannot replace it — you can't buy your way into the spotlight, and the “★ FEATURED” cards are picked by the Flareo team based on the same criteria a senior operator would use.

We also publish a per-category trending strip computed weekly from the same signals. New modules with strong early reviews appear there fastest — reviews from real operators are the single highest-weighted signal, more than deploy count or trust score on their own.

Anti-game commitments: we don't sell promotion, we don't auction featured slots, we don't accept payment in exchange for catalog visibility, and we publish the ranking weights in our docs so you can audit them. If we ever take ad money, the implementation will be explicit ad slots clearly labeled and never mixed into organic rank.

The criteria above (what gets approved, what gets delisted, the SLA, the analytics surface) form a contract we've made with every existing publisher. Changing those criteria mid-stream isn't free — existing modules might no longer qualify under tightened rules.

Our commitment: any policy change that could affect existing modules' status (e.g. tightening CVE thresholds, adding new build constraints) gets 30 days of advance notice for Free / Pro publishers and 60 days for Enterprise. The notice goes to the email on file, appears on the publisher's dashboard, and is published on /changelog.

Loosening policies (allowing more modules) ships immediately and announces in the changelog. Tightening policies — never without notice.