Platform · 2026
OpenForge
A self-hosted app store for open source — discover, analyse and launch projects behind a review-gated sandbox.
2 Search engines
Platform
2026
Key decisions
- Search runs two engines at once, Meilisearch for keyword lookup and Qdrant for vector search, because a single index answers one of those questions badly.
- Project profiles and evidence refreshes are computed by Celery workers on dedicated ingestion and analysis queues rather than at request time, so browsing stays fast and the expensive work happens once.
- Executing an actor run requires sandbox confirmation, an allow-level policy decision, passed build-scan evidence and a pinned Docker image, because a store that silently runs strangers' code is a liability rather than a feature.
- The analysis passes go through an OpenAI-compatible endpoint defaulting to a local Ollama instance, so the AI features never require an external API key.
Discovery is the unsolved half
Open source has excellent distribution and poor discovery. GitHub Trending shows you what is briefly popular, not what does the job you have. Finding the right project still means reading twenty READMEs.
OpenForge pulls projects in four ways — GitHub trending (daily, weekly,
monthly), arbitrary GitHub search queries, awesome-list READMEs parsed for
repository links, and direct owner/name imports — and every import is
processed asynchronously by Celery workers on dedicated ingestion and analysis
queues. The catalogue is searchable two ways at once: Meilisearch for
keyword and typo-tolerant lookup when you know the name, Qdrant for vector
search when you only know the shape of the problem, with named vectors across
four domains — catalogue text, README, runtime and trust — fused behind a
single unified search endpoint with reciprocal-rank fusion. Those are different
questions and a single index answers one of them badly.
Analysis before install
Each project gets an analysed dossier rather than a bare README link: health, activity and popularity scores, OpenSSF Scorecard evidence, release and changelog cadence, sampled issue-response and resolution signals, and package intelligence — PURL identities, dependency edges, and OSV advisories. External metadata from deps.dev, ecosyste.ms and the npm and PyPI registries stays local-only unless the operator explicitly opts in. The LLM passes — summary, use cases, pros and cons, embeddings — go through any OpenAI-compatible endpoint, defaulting to a local Ollama instance, so the AI features never require an external API key.
All of it is computed by Celery workers and stored in PostgreSQL 16 across 36 Alembic migrations, so browsing stays fast and the expensive work happens once. Refreshes of stale evidence are dry-run by default and only execute on explicit operator confirmation.
Sandboxed launch
The store metaphor only completes if you can actually run the thing, and that
is exactly where an app store for strangers’ code can hurt you. Launch plans
are review-only: they generate steps, risks and confirmations without
executing anything. Actor builds can be scan-reviewed with Syft, OSV-Scanner,
Grype, Gitleaks and OPA when the operator opts in, and actually executing a
run requires sandbox confirmation, an allow-level policy decision, passed
build evidence and a pinned Docker image before a Celery worker touches it.
The default strict_local policy profile denies privileged containers and
host Docker socket mounts and disables network egress. That is the difference
between a catalogue and a store — and between a store and a liability.
Next.js 16 with React 19, shadcn/ui and TanStack Query on the front, FastAPI
over PostgreSQL 16 behind, an openforge CLI shipped with the backend
package, and an optional Temporal worker that mirrors the six workflow
contracts when a Temporal server is configured.