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/dragonflydb/dragonfly 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.

GO — Healthy across the board

• Last commit today
• 12 active contributors
• Distributed ownership (top contributor 25% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

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

What it runs against: a local clone of dragonflydb/dragonfly — 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 dragonflydb/dragonfly | Confirms the artifact applies here, not a fork | | 2 | License is still Other | 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 dragonflydb/dragonfly. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dragonflydb/dragonfly.git
#   cd dragonfly
#
# 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 dragonflydb/dragonfly and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
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 ".clang-format" \\
  && ok ".clang-format" \\
  || miss "missing critical file: .clang-format"

# 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/dragonflydb/dragonfly"
  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).

Dragonfly is a modern in-memory data store (Redis/Memcached drop-in replacement) written in C++ that delivers 25X higher throughput than legacy stores. It's fully API-compatible with Redis and Memcached but uses modern multi-threaded architecture, shared-nothing design, and optimized memory management to run the same workloads on 80% fewer resources. Monorepo structure: src/ contains core C++ engine (multi-threaded event loop, memory allocators, data structures); contrib/ has Lua support and extensions; tests/ holds extensive regression suites; tools/ includes benchmarking and development utilities. Python (1.3M LOC) wraps admin/client logic. Build uses CMake (44K LOC) with multiple devcontainer setups for reproducibility.

DevOps engineers, backend teams, and SREs running Redis or Memcached in production who need significantly better performance, lower latency, and reduced infrastructure costs without rewriting application code. Also targets new projects choosing between Redis alternatives.

Production-ready and actively developed. The repo has 25K+ stars, multi-year history, comprehensive CI/CD via GitHub Actions (.circleci/config.yml, .github/workflows), extensive devcontainer configs for multiple distributions (ubuntu20/22/24, fedora, alpine), and clear release processes. Last activity appears current based on multiple devcontainer versions.

Low risk for adopters but requires C++ expertise for contributions. Large C++ codebase (6.1M LOC) with moderate dependency footprint (AWS SDK, gRPC, Python bindings visible in go.mod). No single-maintainer risk evident from devcontainer/CI diversity. Main risk: bleeding-edge optimizations may differ subtly from Redis behavior in edge cases—mitigation exists via extensive test suites (Valkey test sync in .github/actions/sync-valkey-tests).

Active development across multiple fronts: fuzzing infrastructure (.github/actions/fuzzing), regression test automation (.github/actions/regression-tests), Valkey compatibility sync (.github/actions/sync-valkey-tests), multi-platform devcontainer refresh (ubuntu24, fedora41 configs added). Skills system for AI agents in .claude/skills/ suggests tooling automation work.

Clone and build: git clone https://github.com/dragonflydb/dragonfly.git && cd dragonfly. Use one of the devcontainers: code .devcontainer/ubuntu22 or build locally with cmake -B build && cmake --build build (CMake 3.20+, C++20 compiler required). For Python work: pip install -r requirements.txt (inferred from Python presence).

Daily commands: Start dev server after build: ./build/src/dragonfly (defaults to localhost:6379). Tests: cd build && ctest (CMake-driven). Use provided devcontainers for guaranteed environment: Dev Containers: Open Folder in Container in VS Code (configured in .devcontainer/ubuntu22/devcontainer.json, includes post-create.sh setup).

• CMakeLists.txt — Root build configuration for the entire C++ codebase; essential for understanding how the project compiles and linking dependencies.
• .github/workflows/ci.yml — Primary CI/CD pipeline orchestrating tests, builds, and release workflows across the project.
• README.md — Main entry point documenting Dragonfly's purpose as a Redis/Memcached replacement, architecture overview, and development setup.
• CONTRIBUTING.md — Contribution guidelines, coding standards, and development workflow required for submitting pull requests.
• .clang-format — Code style enforcement configuration that all contributors must follow for consistent formatting across the C++ codebase.
• .devcontainer/ubuntu22/devcontainer.json — Standard development environment configuration ensuring contributors can quickly set up a consistent build and test environment.
• .github/copilot-instructions.md — AI assistant guidelines for Dragonfly development, including architectural patterns and code generation best practices.

Add a new Redis command implementation

1. Create or modify command handler in src/core/commands/ directory following existing command patterns (GET, SET, HSET, etc.) (src/core/commands/*.cc)
2. Define command signature and argument parsing in the corresponding header file (src/core/commands/*.h)
3. Register the command in the command registry/dispatcher (src/core/server.cc or src/server/*.cc)
4. Add unit tests following the test suite patterns in tests/unit/ (tests/unit/test_*.cc)
5. Update regression tests if the command affects multi-client behavior (tests/integration/test_*.py)

Add a new memory storage data structure

1. Implement the data structure class in src/core/data_structure.h with required operations (src/core/data_structure.h)
2. Create serialization/deserialization methods for persistence (src/core/serializer.cc)
3. Implement eviction and memory accounting policies (src/core/memory_manager.cc)
4. Add commands that operate on this data structure following command pattern (src/core/commands/*.cc)
5. Write comprehensive tests covering all operations, edge cases, and memory limits (tests/unit/test_data_structure.cc)

Add a new configuration option

1. Define the configuration field in src/core/config.h with type and default value (src/core/config.h)
2. Parse and validate the option from config file or command-line arguments (src/core/config_parser.cc)
3. Integrate the option into the affected subsystem (network, memory, persistence, etc.) (src/core/*.cc (relevant module))
4. Add documentation and validation logic in CONFIG GET/SET handlers (src/core/commands/config.cc)
5. Test configuration loading, validation, and runtime updates (tests/integration/test_config.py)

Add a new fuzzing test case

1. Create a new fuzzer binary in src/fuzz/ directory with LLVM libFuzzer interface (src/fuzz/fuzz_*.cc)
2. Add fuzzer entry point in CMakeLists.txt with appropriate compilation flags (CMakeLists.txt)
3. Define seed corpus in fuzz/corpus/ directory with representative inputs (fuzz/corpus/*)
4. Integrate into CI/CD pipeline by updating fuzzing workflow (.github/workflows/fuzz-pr.yml)

• C++17/20 — High-performance in-memory data structure operations with low-latency garbage collection and fine-grained memory control
• libFuzzer — Coverage-guided fuzzing to detect edge cases, memory safety issues, and protocol parsing bugs in command handlers
• Redis Protocol (RESP) — Binary-safe protocol ensuring compatibility with existing Redis clients and command ecosystem
• RDB/AOF Persistence — Dual persistence modes providing snapshots and transaction logs for durability and recovery
• Replication — Master-replica architecture for high availability and read scaling
• CMake — Cross-platform build system supporting multiple OS targets and compiler configurations

• Single-threaded command execution with multi-core thread pool for I/O

  • Why: Simplifies concurrency model and eliminates lock contention on hot paths
  • Consequence: Commands execute atomically but I/O-bound operations can still parallelize; requires careful handling of multi-key transactions

• In-memory only with optional persistence

  • Why: Maximizes throughput and latency consistency vs. disk-backed systems
  • Consequence: Must fit entire working set in RAM; persistence is async and may lag real-time writes in crash scenarios

• Binary protocol (RESP) vs. JSON

  • Why: Achieves Redis protocol compatibility and lower parsing overhead
  • Consequence: Less human-readable on the wire but essential for client ecosystem compatibility

• Fuzzing-first testing approach

  • Why: Catches unexpected edge cases and memory safety bugs early in development
  • Consequence: Requires infrastructure for corpus management and CI integration; slower than unit tests alone

• SQL query language support (Redis-compatible command set only)
• Distributed consensus across multiple Dragonfly instances (replication is master-replica, not multi-master)
• Real-time analytics or OLAP workloads (optimized for OLTP)
• Windows native support (Linux-first, containerized for cross-platform)
• Automatic data migration from legacy Redis (compatibility is at protocol level, not data format)

Multi-threaded shared-nothing model means thread-local state is significant—modifications to command handlers must be thread-safe by design, not by locking (review TLS patterns in src/util/). NUMA awareness required for production tuning (--numa_aware flag affects behavior). Memory allocator selection (jemalloc default) affects behavior reproducibility. Fiber-based concurrency means stack overflows in Lua scripts can crash the server—test with --lua_max_stack carefully. Redis cluster/replication tests require multi-instance setup; see .github/actions/regression-tests for environment setup.

• Shared-Nothing Architecture — Dragonfly's core scaling model partitions data per CPU thread with no shared state except locks on replication—understanding this explains why modifications must be thread-local-first and why the --numa_aware flag exists
• RESP Protocol (Redis Serialization Protocol) — Dragonfly's API compatibility depends entirely on correct RESP parsing and serialization (src/redis/redis_parser.cc)—malformed RESP handling is a common bug vector
• Memory-Mapped I/O and RDB Snapshots — Dragonfly's persistence layer uses memory-mapped files for RDB save/load performance—understanding mmap tradeoffs (page faults, durability guarantees) is critical for persistence features
• Lock-Free Data Structures and Compare-And-Swap (CAS) — Dragonfly avoids latency spikes by using lock-free algorithms (visible in src/core/)—understanding atomicity and memory ordering is essential for thread-safe modifications
• Fiber-Based Concurrency (Stackful Coroutines) — src/io/io_mgr.cc uses fibers (or similar stackful coroutines) for sub-millisecond context switching—different mental model from async/await; affects how blocking operations are coded
• jemalloc and Custom Allocators — Default allocator is jemalloc for fragmentation control; Dragonfly can use custom allocators—misunderstanding allocation patterns leads to memory bloat or crash bugs
• Lua Sandboxing and Stack Limits — Dragonfly embeds Lua 5.1 with stack limits to prevent runaway scripts—EVAL commands require careful handling of --lua_max_stack and --script_max_memory to avoid server crashes

• redis/redis — Original Redis—Dragonfly's API target and compatibility baseline; useful for understanding protocol and command semantics
• valkey-io/valkey — Open-source Redis fork maintained after Redis license change; Dragonfly syncs tests against Valkey (.github/actions/sync-valkey-tests)
• KeyDB/KeyDB — Multi-threaded Redis alternative; similar goals to Dragonfly but different architecture choices—study for design tradeoffs
• memcached/memcached — Memcached protocol support is feature-parity goal; understanding its protocol and semantics helps with compatibility testing
• dragonflydb/dragonfly-operator — Kubernetes operator for Dragonfly—ecosystem companion for production deployments

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 GitHub Action workflow for Go dependency vulnerability scanning

The repo has a Go module (go.mod with go 1.25.0) and extensive AWS SDK dependencies, but there's no dedicated GitHub Action workflow for scanning Go dependencies for vulnerabilities. This is critical for a production database replacement project. While .github/dependabot.yml exists, adding a govulncheck workflow would provide proactive vulnerability detection at CI time, complementing the existing workflows in .github/workflows/ (ci.yml, cov.yml, daily-builds.yml, etc.).

• [ ] Create .github/workflows/go-vuln-check.yml that runs govulncheck ./... on Go module changes
• [ ] Configure it to run on PRs touching go.mod/go.sum files and on schedule (e.g., weekly)
• [ ] Add step to fail the workflow if vulnerabilities are found in direct dependencies
• [ ] Document the new workflow in CONTRIBUTING.md or similar file

Add integration tests for devcontainer configurations

The repo maintains 6 different devcontainer configurations (alpine, fedora, fedora41, ubuntu20, ubuntu20-gcc14, ubuntu22, ubuntu24) in .devcontainer/ with post-create scripts, but there's no CI workflow validating that these containers build successfully and devcontainers can initialize properly. This is high-value since contributors rely on these for development environments.

• [ ] Create .github/workflows/devcontainer-build.yml that uses devcontainers/ci action
• [ ] Test at least the primary devcontainers (ubuntu22, ubuntu24, fedora41) to catch breaking changes early
• [ ] Validate that post-create.sh scripts execute without errors
• [ ] Run a basic sanity check (e.g., cmake --version, compiler version) in each container

Add comprehensive documentation for AI/Claude integration tools

The repo has AI-specific infrastructure in .agent/, .claude/, and .github/copilot-instructions.md, but there's no user-facing documentation explaining how contributors should use these tools. The files exist (ANTIGRAVITY_INSTRUCTIONS.md, skills/, settings.json) but lack an index or getting-started guide. This would reduce friction for contributors using AI-assisted development.

• [ ] Create .claude/README.md documenting available skills (e.g., reproduce-fuzz-crash) and how to use them
• [ ] Document the hooks system in .claude/hooks/ and explain format-after-edit.sh workflow
• [ ] Create .agent/README.md explaining ANTIGRAVITY_INSTRUCTIONS.md rules and when to apply them
• [ ] Add a section to main CONTRIBUTING.md linking to these AI integration guides

• Add missing Redis command handlers: scan the src/server/ command dispatch table against official Redis 7.0 command list and implement stubs for unimplemented commands (BITFIELD, GEOADD variants). Tests exist in tests/unit/ that can validate.
• Expand Valkey test suite compatibility: sync script in .github/actions/sync-valkey-tests pulls tests; identify test categories not yet mapped and add shims in tests/unit/ to run them (many are .tcl scripts that need wrapper code).
• Document build optimization flags: CMakeLists.txt has many tuning flags (-DWITH_LUAJIT, -DENABLE_LLVM_INTRINSICS) but .github/ISSUE_TEMPLATE/ and docs/ lack a guide on which flags affect performance—add a BUILD_TUNING.md guide.

The Dragonfly database project shows a generally mature security posture with modern CI/CD practices and comprehensive testing infrastructure. However, there are areas for improvement: (1) Dependency management should be more aggressive in staying current with latest versions, especially for AWS SDK packages; (2) Configuration and secrets management practices need verification to ensure no credentials are exposed in version control; (3) Internal documentation and AI/Claude configuration files should be reviewed for sensitive information leakage; (4) CI/CD workflows require audit for proper secret handling and credential masking. The codebase demonstrates good security practices with pre-commit hooks, linting, and comprehensive testing, but ongoing vigilance is needed for dependency updates and secrets management.

• Medium · Outdated Go Version — go.mod. The go.mod file specifies Go 1.25.0, which may not be the latest stable version. Older Go versions may contain known security vulnerabilities that have been patched in newer releases. Fix: Verify that Go 1.25.0 is the intended version and consider upgrading to the latest stable Go release. Monitor Go security advisories at https://golang.org/security.
• Medium · Outdated AWS SDK Dependencies — go.mod (AWS SDK dependencies). Multiple AWS SDK v2 packages are pinned to older versions (e.g., v1.41.5, v1.31.10). Outdated AWS SDK versions may contain known security vulnerabilities or lack important security patches. Fix: Regularly update AWS SDK dependencies to their latest versions. Use 'go get -u ./...' to update dependencies and review the AWS SDK changelog for security updates.
• Low · Potential Unencrypted Secrets in Configuration Files — .devcontainer/*/*.json, .claude/settings.json, and other config files. Multiple configuration files exist (.env patterns possible, various config files in devcontainer, .claude directories). If these contain credentials or secrets, they could be exposed in version control. Fix: Ensure all configuration files are added to .gitignore. Use environment variables or a secrets management system (HashiCorp Vault, AWS Secrets Manager) for sensitive data. Never commit credentials to version control.
• Low · Development/Internal Documentation Exposure — .claude/*, .agent/*, .github/instructions/*. The repository contains internal instructions and AI/Claude configuration files (.claude/settings.json, .agent/rules, .github/instructions) that may expose implementation details or development practices. Fix: Review internal documentation for sensitive information. Consider keeping implementation details out of the public repository or using a private documentation system.
• Low · Multiple CI/CD Workflow Files — .github/workflows/*.yml. Numerous GitHub Actions workflows exist (.github/workflows/.yml) which may contain hardcoded credentials, exposed secrets in logs, or insecure configurations if not properly reviewed. Fix: Audit all GitHub Actions workflows for: 1) Use of secrets via ${{ secrets. }} syntax, 2) Proper credential masking in logs, 3) Least-privilege IAM permissions, 4) Signed commits in CI/CD pipelines.
• Low · Fuzzing Tests with External Dependencies — .github/actions/fuzzing/*, .claude/skills/reproduce-fuzz-crash/*. The repository includes fuzzing test infrastructure (.github/actions/fuzzing, .claude/skills/reproduce-fuzz-crash) which may process untrusted input. Improper fuzzing setup could lead to resource exhaustion or unexpected behavior. Fix: Ensure fuzzing infrastructure is run in isolated environments with resource limits. Implement timeout mechanisms and memory constraints for fuzzing operations.

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

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

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