Five categories: shipped, in progress, planned (committed with a date), considered (we're thinking about it, not promising it), and parked (deliberately not on the path). Items move between categories as reality changes — this page is the record.
Distinct discovery surface (/marketplace) with editorial picks, trending modules, and inline reviews. Authenticated /pipeline page that walks every stage with real artifacts (BuildKit log, Trivy report, CycloneDX SBOM, SLSA in-toto, cosign + Rekor, ECR publish receipt).
open marketplace →Env-gated demo signin lets dev environments bypass OAuth for testing. Hard-locked behind NODE_ENV != production AND DEMO_MODE=1; route returns 410 in prod regardless.
Full marketplace social fabric: per-module reviews with moderation, /@username profile pages, admin-curated featured strip, public report inbox for module problems.
Real submission build-worker (BullMQ-coordinated, BuildKit + Trivy in DinD, deterministic job claiming), live build log streaming via SSE, plan-aware quotas, Stripe billing for Pro / Enterprise tiers.
First launch cohort: vaultwarden, uptime-kuma, authentik, nginx-proxy-manager, gitea, immich, caddy, grafana, crowdsec, keycloak, forgejo, jellyfin. Each with republish receipts and a visible lastRebuiltAt timestamp.
/verify accepts any public OCI image — Docker Hub, GHCR, Quay, public.ecr.aws, anywhere. For Flareo-cataloged digests you get the full receipt chain; for external signed images, you get signer identity, OIDC issuer, and the Rekor log entry. Pre-auth, no Flareo trust required to use.
audit an image →/api/v1/modules/<slug>/takeaway returns a single markdown file with all four deployment artifacts (compose, Helm values, .env, docker run) plus a README explaining how to verify before deploying. Cacheable with the module's digest as ETag, so cache invalidates exactly when the module rebuilds.
Publish wizard adds a build-mode picker — "I have a Dockerfile" or "Auto-detect with buildpacks." CNB path detects language from root markers (package.json, go.mod, Cargo.toml, etc.) and pins a specific Paketo builder. Detection runs server-side at submission time so reviewers see the language we'll build before they decide. Pipeline downstream is identical to the Dockerfile path — same Trivy, same SBOM, same signature.
see pipeline stage 01 →Reviewer admin surface at /app/admin/vex lets the team annotate Trivy findings with not_affected / under_investigation / fixed / affected. Annotations roll up into an OpenVEX 0.2.0 document downloadable at /api/v1/modules/<slug>/vex, included on every module detail page receipts panel, surfaced in pipeline stage 04. Publisher-side annotation surface remains a follow-up.
see pipeline stage 04 →Active admission policy at /app/admin/policy with full revision history (every save creates a new revision; older ones stay in the audit trail). Pure-TypeScript evaluator runs against every module's signals (CVE counts after VEX, SLSA level, signature/SBOM/Rekor presence, trust score). Verdict cached per module, downloadable at /api/v1/modules/<slug>/policy. Honest framing: OPA-shaped JSON policy today; Rego runtime is a future swap behind the same input/output contract.
see pipeline stage 07 →A Docker Compose bundle that lets a team run their own Flareo on their own hardware. The architecture supports it (control-plane + execution-plane separation, standard OSS dependencies). What's missing is the packaging, license decision, and support story — committed to make those calls in Q4.
Pick two modules in the same category, see side-by-side Trust Scores, CVE counts, SBOM size, last update, deploy count, signature recency. Turns the marketplace from browsing into decision-making.
The proposal called this 'the single highest-value content element' — one button on the landing that spins up a real running module in a real sandbox in 10 seconds. Real engineering: Caddy dynamic reverse proxy, wildcard TLS, isolated subdomain per session, abuse mitigation. Significant work; we want to commit to a date only when we know we can deliver.
Today, Flareo is exposure-only for submitters. Revenue share for the most-deployed modules on the Pro tier is a possibility we're not yet committing to. The reason for the hold: it changes supply-side incentives in ways we'd rather understand from data than from speculation. If we move, we publish the model in detail before activating.
Three positions in tension: keep weights fixed (canonical comparison), tunable for organizations (Enterprise tier), or tunable for everyone with the canonical still visible. Holding the question open until we see whether the demand is there.
open methodology page →A 'new verified modules this week' feed that compounds over time and pulls in return traffic. Cheap to build; valuable only once the catalog is large enough that it's worth subscribing.
The product is a developer tool. Developers verify, deploy, and operate from terminals and laptops. A mobile app is the wrong investment unless and until the audience materially shifts.
Initially planned, then realized the use case (paste a digest, see if Flareo built it) is already covered by /verify — and a search-by-hash UI duplicates that flow without adding value. Parked indefinitely.