GO — Healthy across the board

• Last commit today
• 18 active contributors
• Distributed ownership (top contributor 25% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Quickwit is a cloud-native, full-text search engine written in Rust specifically optimized for observability workloads (logs, traces, metrics). It provides an Elasticsearch-compatible API and runs efficiently on cloud object storage (S3, GCS, Azure), making it a cost-effective alternative to Datadog, Elasticsearch, Loki, and Tempo for distributed tracing and log management. Monorepo structure with multiple Rust workspaces under .cargo/config.toml, supporting cloud storage backends (S3, GCS, Azure via configuration). The .claude/skills/ directory reveals Claude-assisted workflows for dependency management (bump-tantivy, rationalize-deps). CI/CD defined in .github/workflows/ with specialized pipelines for datafusion integration, lambda packaging, and nightly builds. Web UI components present (TypeScript 133KB) alongside core Rust engine.

DevOps engineers, SREs, and platform teams building observability infrastructure who need to ingest and search massive volumes of logs and traces without the cost and operational overhead of Elasticsearch or proprietary solutions. Also appeals to open-source advocates wanting Jaeger-compatible distributed tracing on cloud storage.

Production-ready and actively developed. The repository shows 10.1MB of Rust code indicating substantial codebase, recently released v0.8 per the README, and has comprehensive GitHub Actions CI/CD workflows (.github/workflows/) covering unit tests, coverage, Docker builds, and cross-platform binary publishing. Last activity visible in workflows and multiple active integration paths (Jaeger, Grafana, Elasticsearch clients).

Low-to-moderate risk for adoption. Rust codebase mitigates memory safety issues, but rapid feature development (v0.8 recent) suggests possible breaking changes. Metrics support is still on the roadmap rather than shipped. Single-language dominance (Rust 10.1MB vs other langs) means contributor pool is smaller than polyglot projects. No visible evidence of formal security audit, though OpenSSF Scorecard badge is present.

Recent release of v0.8 (per README blog post link). Active CI/CD with workflows for Docker image publishing (publish_docker_images.yml), nightly package builds, and cross-platform binary builds (Linux, macOS via custom actions/cargo-build-macos-binary/). Development includes integrations with Jaeger (native support), Grafana, and Elasticsearch clients. Metrics support actively being roadmapped.

git clone https://github.com/quickwit-oss/quickwit.git
cd quickwit
# Install Rust (if not present): curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release
# or use devcontainer: code . # and reopen in container (see .devcontainer/devcontainer.json)

Daily commands:

# Development server (depends on workspace structure, likely)
cargo run --bin quickwit-cli -- help
# or server mode
cargo run --bin quickwit-server
# Docker
docker build -t quickwit:latest .
docker run -p 7280:7280 quickwit:latest
# See .devcontainer/ for containerized development environment

• Cargo.toml — Root workspace manifest defining all crates, dependencies, and workspace members for the Rust-based search engine
• README.md — Project overview, feature set, and getting started guide that orients all contributors to Quickwit's mission as a cloud-native search engine
• CONTRIBUTING.md — Contribution guidelines and development workflow conventions that all contributors must follow
• CODE_STYLE.md — Rust code style, formatting, and architectural patterns enforced across the codebase
• .github/workflows/ci.yml — CI/CD pipeline definition that gates all merges and defines the build/test contract
• config/quickwit.yaml — Default configuration schema and example for running Quickwit, essential for understanding runtime behavior
• Makefile — Build and development targets for compiling, testing, and running the search engine locally

Add a new index configuration template

1. Create a new YAML file in config/templates/ following the gh-archive.yaml pattern with your data source schema (config/templates/my-datasource.yaml)
2. Define index fields, analyzers, and search settings matching your observability use case (logs, metrics, traces) (config/templates/my-datasource.yaml)
3. Add corresponding tutorial configuration in config/tutorials/my-datasource/ with actual ingestion pipeline (Kafka source, OTEL collector config, etc.) (config/tutorials/my-datasource/index-config.yaml)
4. Update README.md with link to new template and supported data sources (README.md)

Add a new GitHub Actions CI workflow

1. Create new workflow YAML in .github/workflows/ referencing existing CI patterns (cargo test, clippy checks) (.github/workflows/my-feature-ci.yml)
2. Define job matrix for multiple Rust versions and target platforms using cross-compilation docker images (.github/workflows/my-feature-ci.yml)
3. Configure GitHub branch protection rules to require workflow success before merge (.github/workflows/my-feature-ci.yml)
4. Document workflow purpose and dependencies in CONTRIBUTING.md (CONTRIBUTING.md)

Add a new cross-compilation target

1. Create Dockerfile in build/cross-images/ with target architecture (e.g., aarch64-unknown-linux-musl.dockerfile) based on existing x86_64 pattern (build/cross-images/aarch64-unknown-linux-musl.dockerfile)
2. Update .cargo/config.toml with linker and rustflags for new target (.cargo/config.toml)
3. Add build step in .github/workflows/ci.yml to test cross-compilation target (.github/workflows/ci.yml)
4. Update distribution CI workflow to publish binaries for new architecture (.github/workflows/publish_cross_images.yml)

• Rust + Tantivy — Memory-safe systems language with zero-copy indexing library enables high-performance, reliable search engine without GC pauses critical for observability at scale
• Cloud object storage (S3/GCS/Azure Blob) — Decouples compute from storage enabling horizontal scaling, cost-effective retention of immutable index segments, and multi-region deployment
• Docker + Kubernetes — Cloud-native architecture for containerized deployment, auto-scaling, and integration with observability stacks (OTEL, Prometheus, Grafana)
• YAML configuration — Human-readable templating for index schemas, data sources, and retention policies matching industry standards (Elasticsearch, Loki compatibility)
• Multi-protocol ingestion (Kafka, Kinesis, Pulsar, gRPC, HTTP) — Flexibility to integrate with existing log/metric/trace collectors (Fluent Bit, Vector, OpenTelemetry) in heterogeneous observability pipelines

• Immutable segments + eventual consistency

  • Why: Simplifies distributed consensus, enables cheap replication to object storage, avoids complex MVCC logic
  • Consequence: Slight latency between ingestion and searchability; aggregation queries must wait for segment merges

• Cloud object storage as primary backend vs local disk

  • Why: Enables stateless compute nodes and true horizontal scaling without distributed consensus overhead
  • Consequence: Network latency on first search after node restart (mitigated by in-memory cache); higher cloud storage costs vs. local NVMe

• Tantivy (embedded library) vs. managed service

  • Why: Lower operational overhead, single-node deployments, no separate process management, full control over indexing parameters
  • Consequence: Developers own performance tuning; no out-of-the-box multi-node Tantivy clustering (handled at Quickwit layer)

• OTEL/OpenTelemetry as primary trace format

  • Why: Vendor-neutral standard reduces lock-in, integrates with existing observability pipelines
  • Consequence: Must maintain compatibility with OTEL schema evolution; traces stored in columnar format may not match exact OTEL wire format

• Does not provide managed SaaS hosting (open-source deployable software only)
• Does not offer multi-tenant isolation guarantees (single-tenant deployment model per instance)
• Does not support real-time stream processing (index-and-query only, not CEP/windowing)
• Does not include authentication/authorization (designed to run behind reverse proxy or VPN)
• Does not guarantee sub-millisecond search latency (targets 10-500ms depending on corpus size)
• Does not handle unstructured binary blobs (JSON/structured logs/traces only)

Environment Setup: Rust toolchain (rustup) is mandatory; ensure you run rustup update after install. Tantivy version pinning: .claude/skills/bump-tantivy/ indicates Tantivy is a critical, managed dependency—breaking upgrades require special handling. Cloud backend credentials: Code accepts S3/GCS/Azure credentials via config; running with --release is strongly recommended for performance testing. DataFusion dependency: Separate CI workflow (datafusion-ci.yml) means DataFusion version changes can cause integration failures. Local setup: .devcontainer/post-create.sh likely runs initialization; check what dependencies (Docker, Docker Compose, localstack via .localstack/) must be running. Breaking changes likely: v0.8 is recent; check CHANGELOG.md for migration notes if upgrading from older versions.

• Columnar Storage & Query Execution (DataFusion) — DataFusion is Quickwit's query engine enabling efficient aggregations and analytics on log/trace data; understanding columnar execution is critical for optimizing query performance
• Inverted Index (Tantivy) — Tantivy powers Quickwit's full-text search; understanding how inverted indices work is essential for grasping why Quickwit is fast for keyword searches on observability data
• Object Storage (S3/Cloud Native) — Quickwit's key differentiator is indexing directly onto S3/GCS instead of local disk; this architecture enables cost-effective multi-tenant observability platforms
• Jaeger Distributed Tracing Protocol — Quickwit integrates natively with Jaeger; understanding trace sampling, span propagation, and the gRPC protocol is needed to use Quickwit for trace analytics
• Elasticsearch Query DSL Compatibility — Quickwit implements a subset of Elasticsearch's REST API and query language to enable zero-migration switching; understanding which features are supported is critical for users
• Bloom Filters (Cardinality & Fast Filtering) — Quickwit likely uses Bloom filters for fast cardinality checks and filtering high-cardinality fields (trace IDs, request IDs) before full index search
• Time-Series Segmentation & Retention — Observability data is inherently time-series; Quickwit's architecture uses time-based indexing segments and retention policies critical for cost management at scale

• elastic/elasticsearch — Direct competitor; Quickwit's Elasticsearch-compatible API is designed for drop-in replacement scenarios
• grafana/loki — Alternative log aggregation engine; Quickwit targets the same log management use case with better cloud storage economics
• jaegertracing/jaeger — Native integration target; Quickwit provides Jaeger-compatible backend for distributed tracing (see distributed-tracing docs)
• quickwit-oss/quickwit-datasource — Official Grafana datasource plugin enabling Quickwit as a metrics/logs backend in Grafana dashboards
• meilisearch/meilisearch — Related search engine (but focused on document search vs. observability); shares cloud-native, Rust-first philosophy

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive tests for .claude/skills/ custom skill definitions

The repo has a sophisticated .claude/skills/ directory with 6 custom skills (bump-tantivy, fix-clippy, fmt, rationalize-deps, sesh-mode, simple-pr) but no visible test coverage or validation framework. New contributors could add tests to verify skill SKILL.md files are valid, properly formatted, and executable. This ensures the developer experience stays high as skills are added/modified.

• [ ] Create tests/claude_skills_test.rs or similar to validate SKILL.md structure
• [ ] Add JSON schema validation for skill definitions in .claude/skills/*/SKILL.md
• [ ] Add integration test that verifies each skill's example commands execute
• [ ] Document skill authoring guidelines in CONTRIBUTING.md with examples

Add cross-platform CI validation for devcontainer configuration

The .devcontainer/devcontainer.json exists but there's no GitHub Action that validates the devcontainer builds successfully on PRs. Given the project supports multiple architectures (aarch64, x86_64) and targets (musl, gnu), a new contributor could add a workflow that tests the devcontainer builds and the post-create.sh script executes without errors.

• [ ] Create .github/workflows/devcontainer-ci.yml that builds devcontainer on main and PRs
• [ ] Add validation that .devcontainer/post-create.sh executes successfully
• [ ] Test on both linux/amd64 and linux/arm64 to match build/cross-images/ targets
• [ ] Add failure notifications to catch devcontainer rot early

Create GitHub Action to validate Cargo.lock and dependency hashes match Pipenv requirements

The repo has .github/workflows/dependency.yml but inconsistent pinning across .cargo/config.toml (Rust) and .github/workflows/requirements.txt (Python). A new contributor could create a validation workflow that ensures dependency hash mismatches are caught in CI, preventing supply-chain vulnerabilities and build inconsistencies.

• [ ] Create .github/workflows/dependency-validation.yml
• [ ] Add check that all hashes in .github/workflows/requirements.txt match PyPI records
• [ ] Validate that Cargo.lock is committed and matches resolved dependencies
• [ ] Document dependency update process in CONTRIBUTING.md with links to verification steps

• Add missing Rust unit tests for cloud storage abstraction layer (S3/GCS/Azure backend selection logic) currently untested based on minimal test file presence in monorepo structure
• Document Elasticsearch API compatibility matrix: create a feature compatibility doc listing which ES query DSL features are fully supported vs. partially supported vs. not yet implemented (important for users migrating from ES)
• Implement Prometheus metrics export: add /metrics endpoint exporting Prometheus-compatible metrics (query latency, index size, ingest rate) leveraging existing observability focus

• High · Exposed Service Ports in .env Configuration — .env.example - MAP_HOST_* variables. The .env.example file exposes multiple service ports (Postgres, LocalStack, Kafka, Zookeeper, Azurite, Grafana, Jaeger, Prometheus) to 0.0.0.0 (all network interfaces). This is a development configuration that should never be replicated in production, as it exposes internal services to the public network. Fix: Document security best practices in CONTRIBUTING.md. Set default MAP_HOST_* values to 127.0.0.1 for development. Add warnings in .env.example about production deployments. Implement network policies and firewall rules in production environments.
• High · Default Hardcoded Database Credentials — .env.example - POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB. The .env.example file contains hardcoded default credentials (POSTGRES_USER=quickwit-dev, POSTGRES_PASSWORD=quickwit-dev) that serve as weak defaults. While labeled as example, these credentials may be reused as-is in development environments. Fix: Use environment variable placeholders or generate random credentials. Add a setup script that forces credential changes. Document the requirement to change credentials before any deployment. Consider using secret management systems (Vault, AWS Secrets Manager) for production.
• High · Docker Base Image Using Latest SHA (Rolling Security Risk) — .env.example - *_VERSION=latest variables. While the Dockerfile uses specific SHA256 digests for Node and Rust images (good practice), the dependencies section uses 'latest' for multiple services (POSTGRES_VERSION, PULSAR_VERSION, CP_VERSION, AZURITE_VERSION, JAEGER_VERSION, OTEL_VERSION, PROMETHEUS_VERSION). This creates unpredictable base images in multi-stage builds and may introduce unvetted security patches. Fix: Pin all service versions to specific version numbers (e.g., POSTGRES_VERSION=15.3). Review and test dependency updates before incrementing versions. Implement image scanning in CI/CD pipeline.
• Medium · Outdated Python Dependencies in CI Workflow — .github/workflows/requirements.txt. The pinned Python dependencies in .github/workflows/requirements.txt include packages with potential security considerations. While hashes are provided (good), pipenv 2025.0.4, virtualenv 20.36.1, and platform-specific packages should be regularly audited. The versions appear current but need ongoing monitoring. Fix: Implement automated dependency scanning using Dependabot or similar tools. Run regular security audits with 'pip-audit' and 'safety'. Update dependencies on a regular schedule (monthly/quarterly) and test thoroughly before merging.
• Medium · Incomplete Dockerfile Build Process — Dockerfile - final RUN statement. The Dockerfile has an incomplete RUN statement at the end: 'RUN' with no command specified. This is a build-time issue that will cause Docker build failures and indicates incomplete or broken CI/CD configuration. Fix: Complete the RUN statement with appropriate build commands or remove if not needed. Add build validation in CI pipeline to catch malformed Dockerfiles. Implement linting tools like Hadolint to validate Dockerfile syntax.
• Medium · Missing Security Headers and SBOM Documentation — Repository root - missing SBOM and security scanning configuration. The LICENSE-3rdparty.csv file exists but there's no evidence of automated Software Bill of Materials (SBOM) generation or security scanning in the visible CI workflows. This makes vulnerability tracking of transitive dependencies difficult. Fix: Implement automated SBOM generation (SPDX format) in CI/CD. Use tools like cargo-audit and cargo-deny for Rust dependencies. Integrate with OpenSSF Scorecard (already present) and add OWASP Dependency-Check to workflows.
• Medium · Limited Security Vulnerability Disclosure Process — SECURITY.md. The SECURITY.md file only lists version 0.3.1 as supported and recommends reporting to security@quickwit.io or Discord. There is no multi-party disclosure, embargo timeline, or coordinated CVE process documented. The policy is minimal for a cloud-native system handling observability data. Fix: Enhance security policy to include: vulnerability embargo period (30-90 days recommended), CVE coordination process, supported versions timeline, patch

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/quickwit-oss/quickwit shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live quickwit-oss/quickwit repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/quickwit-oss/quickwit.

What it runs against: a local clone of quickwit-oss/quickwit — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in quickwit-oss/quickwit | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of quickwit-oss/quickwit. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/quickwit-oss/quickwit.git
#   cd quickwit
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of quickwit-oss/quickwit and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "quickwit-oss/quickwit(\\.git)?\\b" \\
  && ok "origin remote is quickwit-oss/quickwit" \\
  || miss "origin remote is not quickwit-oss/quickwit (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "CODE_STYLE.md" \\
  && ok "CODE_STYLE.md" \\
  || miss "missing critical file: CODE_STYLE.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/quickwit-oss/quickwit"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.