Publishing a module

Flareo's catalog is open for third-party submissions. You write a Dockerfile, submit it through the web wizard or CLI, a human reviewer looks at it, and if it clears the bar an automated pipeline builds, scans, signs, and publishes the result. This page walks through what you need, what happens, and how to think about the review.

What you need before you start

A public Git repository with your module's source. Private repos aren't supported at this tier.

A Dockerfile — pasted into the wizard or kept in the repo at a conventional path. The Dockerfile must follow the rules in Submitting a Dockerfile — the short version is "no network during build, pinned base images, reasonable size". The Dockerfile hard cap is 20 KB.

A contact email where we can reach you about the submission. Decisions and build results are sent here automatically.

Optional but nice: a module slug you've already checked. Slugs are unique across the catalog. Popular names like vaultwarden, gitea, uptime-kuma are already taken by our canary set.

The happy path: web wizard

Sign in at flareo.dev/signin and open the publish wizard. Four steps:

1. Source — the repo URL. We clone it at build time and check out the commit you specify.
2. Manifest — module name, version, category, whether it's previewable.
3. Dockerfile — paste the body, drag a file in, or click to browse. Capped at 20 KB. Skipping is allowed but the reviewer will usually ask you to add one before approving.
4. Review & publish — confirm the payload, click Publish.

After the final click, the submission lands in the reviewer queue. You'll get a confirmation email with a tracking ID.

The alternate path: CLI

If you'd rather stay in your terminal:

flareo publish \
  --source github.com/you/your-project \
  --version 1.2.3 \
  --dockerfile ./Dockerfile \
  --contact-email you@example.com

The CLI uploads the Dockerfile to the same R2 bucket the web wizard uses and posts to the same /api/v1/submissions endpoint. Same queue, same reviewers, same timelines.

What the reviewer is looking for

Reviewers look at four things, in rough priority order.

Does the Dockerfile look safe? Specifically: is the base image a well-known one? Does it pin a digest? Does it avoid privileged instructions like --security=insecure? Does the RUN layer try to reach the network (which would fail at build time anyway)? Is the entrypoint reasonable — not a shell script that downloads and runs something?

Does the upstream project seem well-run? We'd rather not publish a module for a project that was abandoned 18 months ago, has three open unresolved CVEs, or has license terms that make rebuilding from source a gray area. AGPL, Apache, MIT, BSD, and MPL are all fine. SSPL and BUSL-with-non-compete clauses we evaluate case-by-case.

Is the module already in the catalog under a different name? If we already have vaultwarden there's no catalog value in also having vaultwarden-password-manager; we'll ask you to pick a different focus or contribute an improvement to the existing module.

Does the slug make sense? Short, lowercase, kebab-case, clearly related to the upstream project. We'll sometimes rename during review if the original is confusing.

What happens after approval

When a reviewer clicks Approve, the build worker picks up the submission within a minute and runs the full pipeline:

1. Fetches your Dockerfile from R2
2. Runs docker build in a network-isolated sandbox
3. Scans the resulting image with Trivy (critical or high CVEs = automatic rejection)
4. Generates an SBOM with Syft
5. Pushes to public.ecr.aws/flareo/<your-slug>
6. Signs with cosign using the Flareo GitHub Actions OIDC identity, which writes the signature to the public Sigstore transparency log
7. Creates the public catalog entry at flareo.dev/modules/<your-slug>

The whole sequence usually takes 5-12 minutes end-to-end. You get an email when it completes — either "Your module is live" with links, or "Build failed" with the reason and a retry path.

What happens if the build fails

Builds fail for three reasons, each handled differently:

User error — your Dockerfile is broken. The email explains what went wrong (non-zero exit from RUN, missing entrypoint, size over the 4 GB ceiling, network access during build, etc). The submission doesn't auto-retry. You fix the Dockerfile and resubmit.

Scan rejection — build succeeded but Trivy found critical or high CVEs in the final image. Email lists the CVEs. Your options: upgrade the vulnerable dependency in your Dockerfile, move to a newer base image, or ask us to reconsider if you think the scanner is wrong (it happens).

System error — our infrastructure hiccupped. Rare. The worker retries automatically three times with exponential backoff (1 min, 5 min, 15 min). If all three retries fail, the submission lands in a dead-letter state and a human investigates. You don't need to do anything.

What happens when upstream ships a CVE after we've published

A critical CVE in a published Flareo module:

1. Pulls the module from the public catalog's default filter immediately. Status flips from verified to failing and the deploy panel shows the CVE details.
2. We track the upstream fix.
3. Once upstream ships, our daily rebuild picks it up and the module is restored, usually within 24 hours of the upstream patch.

Users with pinned digests are still running the vulnerable image — we can't unpublish something that's already been pulled. What we can do is surface the status via the API and the verify tool so your own runbook can gate on it.

Plan limits

Free-tier accounts can have up to 3 concurrent public modules — counting both published modules and in-flight submissions (pending, approved, building). Pro-tier is unlimited public, up to 20 private. Rejected and failed submissions don't count against quota. See the pricing page for the full table.

Review timelines

Free tier: we aim for a first reviewer look within 5 business days. Pro tier: 2 business days. No guarantees during weekends or holidays. Very complex modules (obscure language runtimes, unusual build constraints, license questions) sometimes take longer because we defer to the person on our side who actually knows the space.

Next steps

• Submitting a Dockerfile — the rules your Dockerfile needs to follow
• Writing a good module — what makes a module worth publishing vs one you should fork privately
• Review timelines — SLA story with numbers
• Admission policies — the automatic gates your submission goes through