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/microsoft/garnet 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
• 14 active contributors
• Distributed ownership (top contributor 22% of recent commits)
• MIT licensed
• CI configured
• ⚠ No test directory detected

_{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 microsoft/garnet repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/garnet.

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "Garnet.slnx" \\
  && ok "Garnet.slnx" \\
  || miss "missing critical file: Garnet.slnx"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".azure/pipelines/azure-pipelines.yml" \\
  && ok ".azure/pipelines/azure-pipelines.yml" \\
  || miss "missing critical file: .azure/pipelines/azure-pipelines.yml"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "Version.props" \\
  && ok "Version.props" \\
  || miss "missing critical file: Version.props"

# 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/microsoft/garnet"
  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).

Garnet is a high-performance remote cache-store built on .NET that implements the Redis RESP protocol, allowing it to work with any existing Redis client (like StackExchange.Redis) while delivering significantly better throughput, latency (<300µs at p99.9), and scalability than comparable open-source stores. It provides string operations, analytical features (HyperLogLog, Bitmap), and object operations (sorted sets, lists) with advanced capabilities like cluster sharding, key migration, and replication. Monolithic .NET solution (Garnet.slnx) with core server implementation in C# (13.6M LOC), supporting C++ (121K LOC, likely for performance-critical paths), and wrapped by PowerShell (60K LOC) and Python (22K LOC) tooling. Benchmarking via benchmark/BDN.benchmark/ uses BenchmarkDotNet. Docker support spans 6 platforms (Alpine, AzureLinux, Chiseled, Nano Server, Ubuntu). CI/CD orchestrated via GitHub Actions (.github/workflows/) and Azure Pipelines (.azure/pipelines/).

Backend engineers and platform teams building high-scale distributed systems who need a drop-in Redis-compatible cache with sub-millisecond latencies and extreme throughput, particularly those already invested in .NET or running on Azure infrastructure. Contributors are primarily Microsoft Research engineers and open-source maintainers extending the cache implementation.

Garnet is production-ready and actively developed: it has extensive CI/CD via .azure/pipelines/ (including compliance, performance, and nightly test runs), comprehensive Docker support (6 Dockerfile variants), published NuGet packages with download metrics, and a robust test harness (CodeCoverage.runsettings). The project shows consistent maintenance with GitHub Workflows for code quality (CodeQL, BDN benchmarks, Allure test reporting) and is backed by Microsoft Research.

Low risk for established teams: the primary risk is ecosystem lock-in to .NET/C# (13.6M of 14M LOC) and Azure-native features, so Windows/Linux .NET runtime availability is critical. The large codebase (14M+ LOC) and heavy reliance on internal Microsoft build infrastructure (.azure/pipelines/, compliance scanning) may create onboarding friction for external contributors. No obvious single-maintainer risk given Microsoft backing, but Azure Cosmos integration suggests deprecation risk if cloud product supersedes it.

Active development across multiple fronts: BDN (BenchmarkDotNet) performance benchmarking with published charts, nightly test runs via azure-pipelines-nightly.yml, Docker build automation for multiple OS targets, and compliance scanning (PoliCheck, CredScan) suggesting enterprise hardening. The .github/workflows/ shows recent work on Helm chart integration, external/internal release pipelines, and CodeQL static analysis.

Clone and build:

git clone https://github.com/microsoft/garnet.git
cd garnet
dotnet build Garnet.slnx

For running the server locally, consult the website documentation (https://microsoft.github.io/garnet), as startup scripts likely reside in benchmark/ or are driven via the published garnet-server NuGet tool:

dotnet tool install --global garnet-server
garnet-server

Daily commands: Dev build & test:

dotnet build Garnet.slnx
dotnet test Garnet.slnx

Run benchmarks:

dotnet run --project benchmark/BDN.benchmark/BDN.benchmark.csproj

Run server (after install):

dotnet tool install --global garnet-server
garnet-server --port 6379

For Docker: docker build -f Dockerfile.ubuntu -t garnet:latest . then docker run -p 6379:6379 garnet:latest.

• Garnet.slnx — Solution file defining the entire Garnet project structure; essential for understanding how all modules and components are organized
• README.md — Primary documentation covering Garnet's architecture, RESP protocol implementation, and key features like cluster sharding and replication
• .azure/pipelines/azure-pipelines.yml — Main CI/CD pipeline configuration; defines build, test, and deployment workflows that validate all contributions
• Directory.Build.props — Central MSBuild configuration for all C# projects; controls compiler flags, versioning, and assembly signing across the entire codebase
• Version.props — Version and release metadata management; must be updated for any release and affects all downstream builds
• benchmark/BDN.benchmark/Program.cs — Entry point for performance benchmarking suite; demonstrates how to instrument and measure Garnet's throughput and latency characteristics
• .github/CODEOWNERS — Defines code ownership and review requirements; critical for understanding approval workflows and maintainer responsibilities

Add a new benchmark operation

1. Create a new benchmark class inheriting from OperationsBase in benchmark/BDN.benchmark/Operations/ (benchmark/BDN.benchmark/Operations/OperationsBase.cs)
2. Implement [Benchmark] methods that measure your operation's throughput/latency (benchmark/BDN.benchmark/Operations/BasicOperations.cs)
3. Register the benchmark in Program.cs and add it to the benchmark selector (benchmark/BDN.benchmark/Program.cs)
4. Run the benchmark via dotnet run and verify metrics align with performance expectations (benchmark/BDN.benchmark/BDN.benchmark.csproj)

Add a new Docker variant for a platform

1. Create a new Dockerfile.{platform} with multi-stage build targeting your platform (Dockerfile)
2. Add a GitHub Actions workflow in .github/workflows/docker-{platform}.yml to build and push the image (.github/workflows/docker-linux.yml)
3. Update .dockerignore to exclude unnecessary build artifacts for faster builds (.dockerignore)
4. Test the container locally with 'docker build -f Dockerfile.{platform} .' before pushing (Dockerfile.ubuntu)

Add a new compliance or performance check to CI/CD

1. Create a new Azure Pipeline YAML file in .azure/pipelines/ for your check (e.g., azure-pipelines-custom-check.yml) (.azure/pipelines/azure-pipelines-compliance.yml)
2. Define your check job with appropriate triggers (scheduled, on PR, on merge to main) (.azure/pipelines/azure-pipelines-performance.yml)
3. Update azure-pipelines.yml to include your new pipeline in the main trigger chain (.azure/pipelines/azure-pipelines.yml)
4. Verify the pipeline runs successfully and reports results to GitHub checks (.azure/pipelines/credscan-exclusion.json)

Update project version and NuGet release

1. Increment the version number in Version.props following semantic versioning (Version.props)
2. Ensure all package versions are pinned in Directory.Packages.props (Directory.Packages.props)
3. Trigger the release pipeline via .azure/pipelines/azure-pipelines-external-release.yml or internal release pipeline (.azure/pipelines/azure-pipelines-external-release.yml)
4. Verify the release creates NuGet packages (microsoft.garnet and garnet-server) and publishes to nuget.org (Directory.Build.props)

• C# / .NET — Native memory management, SIMD optimizations, and cross-platform runtime for high-throughput cache operations
• RESP Protocol — Redis-compatible wire protocol enabling drop-in replacement with existing Redis clients and ecosystem
• BenchmarkDotNet — Rigorous microbenchmarking framework to measure and track throughput/latency regressions across releases
• Docker / Multi-platform containers — Unified deployment across Linux, Windows, and Alpine variants with minimal configuration drift
• Azure Pipelines & GitHub Actions — Enterprise CI/CD for compliance scanning, performance regression detection, and automated multi-platform releases

• RESP protocol compatibility over custom binary protocol

  • Why: Massive ecosystem benefit and ease of adoption by existing Redis users
  • Consequence: Text-based wire protocol has overhead compared to binary; mitigated by SIMD parsing optimizations

• In-memory cache with optional persistence (AOF/RDB) vs pure in-memory

  • Why: Provides durability and recovery options without forcing every deployment to pay persistence cost
  • Consequence: Adds background write complexity; trade-off between consistency guarantees and throughput

• Cluster sharding via consistent hashing

  • Why: Enables horizontal scaling and key migration without re-hashing entire dataset
  • Consequence: Added routing and replication complexity compared to single-node deployment

• Strong naming and signed assemblies

  • Why: Enterprise security and supply-chain integrity (Garnet.snk)
  • Consequence: Slightly longer build time and key management overhead

• Does not provide built-in authentication or ACL enforcement (relies on network isolation or proxy layer)
• Not a general-purpose relational database; optimized for key-value and in-memory data structures
• Does not handle client-side sharding or multi-key transactions across different cluster nodes
• Not a real-time stream processing engine; designed for low-latency lookup/mutation, not complex aggregations
• Does not include built-in replication conflict resolution; assumes primary-replica topology

Signing key required: Garnet.snk (strong-name key) is present; building release artifacts requires this. Multi-platform targeting: Solutions target both net8.0 (inferred from .NET mentions in README) and platform-specific variants (Windows x64, Linux x64); mismatched targets cause linker failures. Docker complexity: 6 Dockerfile variants (Alpine, AzureLinux, Chiseled, Nano Server, Ubuntu) each with different base images and runtime requirements; ensure you use the correct one for your deployment OS. Compliance gates: .azure/pipelines/ includes PoliCheck and CredScan; PRs may fail on license/credential issues even if code logic is sound; check credscan-exclusion.json and policheck-exclusion.xml before committing secrets or third-party code. NuGet package split: The project publishes two distinct packages (microsoft.garnet library and garnet-server tool); modifying APIs requires careful coordination to avoid breaking consumers.

• RESP (REdis Serialization Protocol) — Garnet's entire wire protocol is built on RESP, enabling drop-in compatibility with any Redis client; understanding request/response framing is critical for protocol extensions.
• Cluster Sharding & Key Migration — Garnet provides transparent cluster sharding and online key migration; understanding how consistent hashing and slot migration work is essential for building distributed deployments.
• Memory-Mapped I/O & Persistence — Garnet's recovery mechanism likely uses mmap for fast crash-consistent snapshots; understanding mmap trade-offs (page faults, fsync semantics) is critical for tuning durability.
• Async/Await Concurrency Model — Garnet is built on C# async/await to handle thousands of concurrent clients efficiently without thread context switching; misuse of synchronous calls can degrade latency.
• HyperLogLog (Cardinality Estimation) — Garnet implements HyperLogLog for approximate distinct count queries with O(1) memory; understanding probabilistic data structures helps predict accuracy-memory trade-offs.
• Bitmap Operations & Bit Manipulation — The benchmark/BDN.benchmark/Bitmap/ module suggests optimized bitwise operations (BITCOUNT, BITFIELD, BITOP); understanding CPU cache alignment and SIMD vectorization helps explain Garnet's latency wins.
• Replication & Consensus — Garnet offers replication features; understanding primary-replica consistency models and write-ahead logging is necessary for building highly available deployments.

• StackExchange/StackExchange.Redis — Official Redis client library for C# that Garnet explicitly supports; understanding this client library is essential for testing Garnet compatibility.
• redis/redis — Original Redis implementation and RESP protocol reference; Garnet's entire protocol layer is designed to be wire-compatible with this.
• dotnet/runtime — The .NET runtime (and coreclr) that Garnet depends on; performance optimizations often require understanding low-level runtime behavior.
• BenchmarkDotNet/BenchmarkDotNet — Micro-benchmarking framework used in Garnet's benchmark/BDN.benchmark/; essential for validating latency and throughput claims.
• Azure/azure-sdk-for-net — Azure SDK for .NET; Garnet integrates with Azure Cosmos DB Garnet Cache and leverages Azure-specific features (Accelerated Networking, managed identities).

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 integration tests for cluster sharding and key migration

The file structure shows extensive cluster functionality (benchmark/BDN.benchmark/Cluster/ with ClusterMigrate.cs, ClusterOperations.cs, ClusterParams.cs) but there's no visible dedicated test suite for these critical features in the provided structure. Cluster sharding and key migration are core features mentioned in the repo description, yet robust integration tests are essential for preventing regressions in distributed scenarios.

• [ ] Create tests/ClusterSharding/ directory with integration test files
• [ ] Add tests for ClusterMigrate.cs covering key migration edge cases (partial migrations, concurrent operations, failure recovery)
• [ ] Add tests for ClusterOperations.cs covering cross-shard operations and consistency
• [ ] Add tests for cluster rebalancing and node failure scenarios
• [ ] Integrate tests into azure-pipelines.yml or ci.yml workflows

Add Dockerfile-specific CI workflow and health check validation

The repo contains 5 different Dockerfiles (Dockerfile, Dockerfile.alpine, Dockerfile.azurelinux, Dockerfile.chiseled, Dockerfile.nanoserver, Dockerfile.ubuntu) but no dedicated workflow to validate they all build successfully and produce working images. This creates a maintenance burden where variants may silently break.

• [ ] Create .github/workflows/docker-build-validate.yml that builds all Dockerfile variants in parallel
• [ ] Add health checks to each Docker build that verify the server starts and responds to basic Redis commands
• [ ] Test basic RESP protocol compatibility for each variant (e.g., PING, SET, GET)
• [ ] Add image size reporting as workflow output to track bloat across variants
• [ ] Document expected image sizes in README.md for each variant

Add security and compliance documentation with specific scanner configurations

The repo has credscan-exclusion.json and policheck-exclusion.xml in .azure/pipelines/, indicating active security scanning, but there's no visible SECURITY.md guidance on how contributors should handle credentials, dependencies, and compliance. SECURITY.md exists but likely needs expansion with specific scanning rules and exclusion rationale.

• [ ] Expand SECURITY.md with explanation of credscan and policheck scanning rules
• [ ] Document why specific files are excluded in credscan-exclusion.json (reference by path)
• [ ] Document why specific content patterns are excluded in policheck-exclusion.xml
• [ ] Add contributor guidelines for adding dependencies (require SBOM/security review)
• [ ] Create DEPENDENCY_POLICY.md documenting NuGet package approval process for microsoft/garnet

• Add benchmark tests for Bitmap operations in benchmark/BDN.benchmark/Bitmap/: the folder has BinaryOperations.cs and UnaryOperations.cs but likely missing edge-case benchmarks (empty bitmaps, max-size bitmaps, cache misses). Create a BitmapEdgeCaseBenchmarks.cs file with scenarios.: Low-risk, well-scoped task that improves performance observability without touching core logic.
• Extend the Dockerfile variants: currently 6 Dockerfiles exist but there's no corresponding documentation in docs/ (inferred) mapping each variant to recommended use-cases (e.g., 'Chiseled for minimal image size' or 'AzureLinux for Azure VMs'). Create a DOCKERFILE_GUIDE.md in the repo root explaining trade-offs.: Helps onboard users and contributors; improves discoverability of deployment options without code changes.
• Audit test coverage gaps: the CodeCoverage.runsettings file defines coverage requirements. Run dotnet test /p:CollectCoverageMetrics=true and identify any .cs files in the core cache logic below the threshold, then add unit tests for uncovered branches (likely edge cases in RESP command parsing or sharding logic).: Increases reliability and test-driven discipline; a good way to learn the codebase incrementally.

Garnet's security posture is generally reasonable for an open-source project, but several configuration and deployment concerns exist. The primary issues are related to default port exposure without authentication, missing TLS/SSL configuration for data in transit, and unpinned Docker base images. The codebase includes proper security reporting channels (SECURITY.md) and active CI/CD pipeline for vulnerability detection. However, deployment configurations should be hardened with authentication, encryption, and network isolation before production use. The static analysis shows no obvious injection vulnerabilities, hardcoded secrets, or critical dependency issues in the visible file structure, but a comprehensive dependency scan of the Directory.Packages.props file would be needed for complete assessment.

• Medium · Docker Base Image Version Not Pinned — Dockerfile (line 1: FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build). The Dockerfile uses 'mcr.microsoft.com/dotnet/sdk:10.0' without a specific patch version. This could lead to unexpected behavior changes or security vulnerabilities when the base image is updated. Using floating tags means the image pulled could differ between builds. Fix: Pin the base image to a specific patch version, e.g., 'mcr.microsoft.com/dotnet/sdk:10.0.x' where x is a specific patch number. Regularly update and test with newer versions in a controlled manner.
• Medium · Exposed Default Redis Port in Docker Compose — docker-compose.yml (ports section: 6379:6379). The docker-compose.yml exposes port 6379 (default Redis port) without any authentication mechanism mentioned in the configuration snippet. This could allow unauthorized access to the cache-store if deployed without proper network isolation or firewall rules. Fix: Implement authentication mechanisms (ACLs, passwords), restrict port access to known IPs via firewall rules, use network_mode 'host' for deployment, or implement reverse proxy with authentication in front of Garnet.
• Medium · Missing Security Headers and TLS Configuration — docker-compose.yml and Dockerfile. The Docker Compose configuration shows no TLS/SSL configuration for the Garnet service. Communication between clients and the cache-store may be transmitted in plaintext, exposing data in transit. Fix: Enable TLS/SSL for Garnet service. Configure certificates in the container and update port bindings to use encrypted connections. Document required TLS configuration in deployment guidelines.
• Low · Incomplete Dockerfile COPY Command — Dockerfile (final COPY command appears incomplete). The Dockerfile snippet appears truncated with 'COPY Garne' incomplete at the end. This suggests the file content provided may be incomplete, potentially hiding configuration issues. Fix: Verify the complete Dockerfile content to ensure all COPY commands are properly formed and no sensitive files are unintentionally included in the image.
• Low · Multiple Dockerfile Variants Without Security Comparison — Multiple Dockerfile variants in repository root. Multiple Dockerfile variants exist (Dockerfile.alpine, Dockerfile.azurelinux, Dockerfile.chiseled, Dockerfile.nanoserver, Dockerfile.ubuntu) without documented security differences or recommendations for which to use in production. Fix: Document the security posture of each Dockerfile variant. Provide guidance on which variant is recommended for production deployments. Regularly scan all variants for vulnerabilities.
• Low · Build Artifacts Exposed Through Multi-Stage Build — Dockerfile (multi-stage build, final stage not provided). The Dockerfile uses multi-stage builds but the final stage is not shown in the snippet. Ensure sensitive build-time files, source code, or secrets are not exposed in the final image layer. Fix: Verify that the final stage only contains necessary runtime artifacts. Remove or exclude build-time dependencies, source code, and any temporary files from the final image.

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.