GO — Healthy across the board

• Last commit today
• 22+ active contributors
• Distributed ownership (top contributor 34% of recent commits)
• MPL-2.0 licensed
• CI configured
• Tests present

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

Vector is a high-performance observability data pipeline written in Rust that collects, transforms, and routes logs and metrics to multiple vendors. It runs as both an agent (on individual hosts) and aggregator (centralized), providing 10x faster throughput than competitors while enabling cost reduction, data enrichment, and security at the edge. Monorepo structured as: src/config/ handles YAML/CUE configuration loading; src/sources/, src/transforms/, src/sinks/ contain pluggable components; tests/integration/ and tests/e2e/ house test suites; website/ contains documentation. Components follow trait-based abstraction allowing extensibility without core engine changes.

DevOps engineers, platform teams, and SREs who need vendor-agnostic log and metric collection without agent sprawl. Organizations like Atlassian, T-Mobile, Comcast, and Discord use it to consolidate observability infrastructure and transition vendors without disrupting workflows.

Production-ready and actively maintained by Datadog's Community Open Source Engineering team. The project has 12.7M lines of Rust code, comprehensive CI/CD workflows (nightly, integration, E2E test suites), and Rust 1.92+ minimum version policy. Version 0.56.0 indicates stable API with continued development for metrics (beta) and traces (coming).

Low risk for core functionality—well-established Rust ecosystem and MPL-2.0 license reduce dependencies. Risk surfaces in feature diversity (agents, aggregators, 50+ components) creating complexity; trace support still in-progress; performance regressions in new component combinations possible. Monitor changelog for breaking changes during pre-1.0 versioning.

Active development on metrics (beta) and traces pipeline; VRL (Vector Remap Language) doc generation improvements (check_generated_vrl_docs workflows); performance optimization (codegen-units=1, fat LTO in release profile); preview site builds and changelog automation via GitHub Actions.

git clone https://github.com/vectordotdev/vector.git && cd vector && cargo build --release. For development: cargo run to start the pipeline, or cargo test to run the test suite (uses nextest via .config/nextest.toml).

Daily commands: cargo run (starts Vector with default config at config/vector.yaml). cargo run --release for optimized binary. cargo test for all tests. nextest run (parallel test execution). cargo bench for benchmarks (autobenches disabled; see inline benchmarks).

• Cargo.toml — Root manifest defining Vector's dependencies, version (0.56.0), MSRV (1.92), and feature flags that control the entire build surface.
• src/config/loading/secret_backend_example.rs — Entry point for the secret-backend-example binary; demonstrates how Vector handles secret management and configuration loading patterns.
• .github/workflows/test.yml — Primary CI pipeline orchestrating unit tests, integration tests, and e2e validation across all components.
• Makefile — Build automation and local development commands; referenced by contributors for compilation, testing, and deployment workflows.
• .rustfmt.toml — Rust code style configuration enforced across all contributions; ensures consistent formatting in this 600-file Rust monorepo.
• CONTRIBUTING.md — Developer guide covering contribution workflow, code standards, testing requirements, and component architecture philosophy.
• STYLE.md — Coding style guide and conventions specific to Vector's Rust codebase, addressing naming, module organization, and design patterns.

• Source Components (sources — undefined

Add a New Source Component

1. Create a new source module under src/sources/ following the naming convention src/sources/your_source.rs (src/sources/your_source.rs)
2. Implement the source trait (likely SourceConfig, Source) with required methods for creating connections and producing events (src/sources/your_source.rs)
3. Register the new source in the source module registry (typically in src/sources/mod.rs) (src/sources/mod.rs)
4. Add integration tests in tests/integration/sources/ validating data flow, error handling, and configuration parsing (tests/integration/sources/your_source.rs)
5. Update Cargo.toml to add any required feature flags and dependencies for optional source functionality (Cargo.toml)

Add a New Sink Component

1. Create a new sink module under src/sinks/ following the naming convention src/sinks/your_sink/mod.rs (src/sinks/your_sink/mod.rs)
2. Implement the sink trait (SinkConfig, Sink) handling event batching, buffering, and endpoint delivery (src/sinks/your_sink/mod.rs)
3. Create src/sinks/your_sink/config.rs for configuration serialization/deserialization (src/sinks/your_sink/config.rs)
4. Add unit tests in src/sinks/your_sink/tests.rs and integration tests in tests/integration/sinks/ (tests/integration/sinks/your_sink.rs)
5. Document the component in website/cue/reference/components/ and update component registry (website/cue/reference/components/sinks/your_sink.cue)

Add a New VRL Function

1. Create the function implementation in src/internal_events/ or src/functions/ following Vector's VRL function patterns (src/functions/your_function.rs)
2. Register the function in the VRL runtime function registry (typically src/vrl/mod.rs or similar) (src/vrl/mod.rs)
3. Add comprehensive unit and integration tests validating all edge cases and error conditions (src/functions/your_function.rs)
4. Document the function signature and behavior in website/cue/reference/vrl/functions/ (website/cue/reference/vrl/functions/your_function.cue)

• Rust 1.92+ (MSRV) — High-performance, memory-safe systems programming; critical for a data pipeline handling observability workloads at scale without garbage collection pauses.
• GitHub Actions + Nextest — Distributed CI/CD with parallel test execution; Vector's 600-file scope requires fast feedback for contributors and maintainers.
• Cargo workspaces + feature flags — Modular component architecture allowing users to compile only required sources, sinks, and transforms; reduces binary size and attack surface.
• VRL (Vector Remap Language) — Domain-specific language for event transformation; safer and more performant than embedding general-purpose scripting.

• Monorepo (600 files) rather than separate packages

  • Why: Unified versioning, shared dependencies, easier refactoring across components; trades module independence for consistency.
  • Consequence: Larger binary footprint if all features enabled; requires feature flags to keep production builds lean.

• MSRV locked at 1.92 rather than nightly-only features

  • Why: Stability and reproducibility across user environments; benefits deployments in older infrastructure.
  • Consequence: Cannot use latest Rust ergonomic improvements; requires backporting or workarounds for new standard library APIs.

• Separate integration/e2e test suites rather than embedded tests

  • Why: Isolate component behavior testing from end-to-end pipeline validation; enables running different test cadences.
  • Consequence: More test infrastructure to maintain; risk of divergence between unit and integration assertions.

• Real-time guarantees (at-least-once delivery model, not exactly-once)
• Storage layer (Vector is stateless, relies on external systems for persistence)
• Built-in query language (VRL is for transformation, not analytics)
• Multi-tenant isolation (designed for single-operator deployments)
• Encryption enforcement (delegates to TLS in sinks/sources)

MSRV is Rust 1.92 (check .cargo/config.toml and Cargo.toml [package.rust-version]). Release builds use fat LTO and codegen-units=1, dramatically increasing compile time—use debug builds for iteration. CUE configuration support requires CUE tooling installed separately (not auto-installed). Tests default to nextest runner; standard cargo test may fail or behave differently. Secret backend feature (secret-backend-example) requires explicit feature flag. Check .github/actions/setup/action.yml for CI-specific environment variables and dependency installation.

• Component trait-based architecture — Vector's extensibility—sources, transforms, sinks are plugins implementing common traits; understanding this lets you add new backends without modifying core
• Event routing DAG (Directed Acyclic Graph) — Vector builds a topology graph where sources fan to transforms fan to sinks; understanding fan-out, filtering, and conditional routing is essential for complex pipelines
• VRL (Vector Remap Language) — Domain-specific language for data transformation inside Vector without spawning external processes; reduces latency and improves safety vs. shell commands
• End-to-end principle (agent vs. aggregator) — Vector's deployment model—agents run on hosts, aggregators centralize; affects configuration, resource usage, and deployment strategy
• Metric cardinality explosion prevention — Unbounded metric labels cause cost and storage issues; Vector provides sampling, downsampling, and metric tagging transforms to manage cardinality
• Async Rust with Tokio — Vector's performance comes from Tokio's async runtime; understanding futures, channels, and task spawning is essential for debugging performance issues

• fluent/fluent-bit — Lightweight log collector; direct competitor in agent space but C-based rather than Rust
• elastic/beats — Elastic's observability agent suite; similar agent-aggregator model but tightly coupled to Elasticsearch ecosystem
• prometheus/prometheus — Metrics collection and storage; Vector routes to Prometheus, often deployed alongside it in observability stacks
• open-telemetry/opentelemetry-collector — Vendor-neutral observability collector supporting traces/metrics/logs; shares Vector's multi-backend vision but different architecture
• goharbor/harbor — Not directly related; included here as Datadog uses harbor—check if Vector distribution/packaging uses container registries

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 Windows-specific integration tests for Vector's core pipeline

The repo has .github/workflows/integration_windows.yml but the integration test suite in tests/integration/lib.rs likely lacks Windows-specific test cases. Vector is a cross-platform observability pipeline, and Windows path handling, file permissions, and process management differ significantly. Adding Windows-targeted integration tests would catch platform-specific bugs early and improve reliability for Windows users.

• [ ] Review existing tests/integration/lib.rs to identify cross-platform gaps
• [ ] Create Windows-specific test module (e.g., tests/integration/windows/) for path handling, file I/O, and service integration scenarios
• [ ] Add test cases for Windows-specific features (e.g., Event Log sources, Windows service integration)
• [ ] Update .github/workflows/integration_windows.yml to execute new Windows-specific test suite
• [ ] Document any Windows-only test setup requirements in docs/DEVELOPING.md

Create comprehensive test coverage for VRL (Vector Remap Language) edge cases in error handling

The repo has infrastructure for VRL documentation (.github/actions/install-vrl-doc-builder/action.yml, check_generated_vrl_docs.yml), but no explicit error-handling test suite is visible in the file structure. VRL is a critical DSL for transformations, and comprehensive edge-case testing (null handling, type coercion failures, recursion limits) would improve stability. This could be a new test file targeting VRL's type system and error propagation.

• [ ] Analyze existing VRL test structure (likely in crates/vrl/)
• [ ] Create new test file crates/vrl/tests/error_edge_cases.rs with comprehensive failure scenarios
• [ ] Test VRL behaviors: null coercion, type mismatches, recursive calls, out-of-memory scenarios
• [ ] Add fuzzing harness integration (if not present) for VRL parsing robustness
• [ ] Update CI workflow check_generated_vrl_docs.yml or create new vrl_tests.yml to run error test suite

Add MSRV (Minimum Supported Rust Version) validation tests for all feature combinations

The Cargo.toml specifies rust-version = "1.92" and there's an msrv.yml workflow, but it likely tests only default features. Given Vector's extensive feature flags (sources, sinks, transforms), MSRV breaks can slip through when new features use syntax incompatible with the declared minimum version. A more comprehensive MSRV CI job would test all feature combinations against Rust 1.92.

• [ ] Audit .github/workflows/msrv.yml to confirm it only tests default features
• [ ] Create script (e.g., scripts/check_msrv_combinations.sh) that tests key feature combinations: --all-features, --no-default-features, and critical sink/source combinations
• [ ] Update msrv.yml to run the new script using cargo +1.92 to validate compile-time compatibility
• [ ] Document MSRV policy in docs/DEVELOPING.md regarding feature gate requirements
• [ ] Add deny.toml or similar to warn on dependencies with higher MSRV requirements

• Add unit tests for src/config/loading/mod.rs validation paths—test invalid CUE/YAML, missing required fields, and type coercion edge cases to improve error messages for misconfigured pipelines.
• Document component feature flags in docs/DEVELOPING.md—several components likely have optional features (see Cargo.toml) but no guidance on which to enable for minimal/full builds.
• Create a runnable example in examples/ showing agent-to-aggregator topology with transform chaining—currently only config/examples/ exists; a working Rust example with comments would help contributors understand multi-component architecture.

The Vector project demonstrates a reasonably mature security posture with CI/CD workflows for security scanning (deny.yml, static-analysis.yml, scorecard.yml) and clear development practices. However, there are configuration issues (invalid Rust edition 2024), incomplete security documentation, and minor concerns around binary artifacts and debug information handling. The codebase itself appears to follow security best practices with code review processes and signed commits mentioned in SECURITY.md. Primary recommendations: fix the Cargo.toml edition specification, complete the SECURITY.md documentation, and enforce commit signatures on protected branches.

• Medium · Deprecated Rust Edition 2024 in Cargo.toml — Cargo.toml (line: edition = "2024"). The Cargo.toml specifies edition = "2024", which does not exist. The latest stable Rust edition is 2021. This will cause compilation failures and indicates potential misconfiguration or use of a custom/unstable toolchain. Fix: Update the edition to a valid value such as '2021' or '2018' depending on the minimum supported Rust version (MSRV) policy. Current MSRV is 1.92, which is compatible with edition 2021.
• Medium · Missing Dependency Audit Configuration — .github/workflows/deny.yml and root configuration. While a 'deny.yml' workflow exists, there is no visible 'Cargo.deny' configuration file in the provided file structure. Without explicit dependency audit policies, supply chain vulnerabilities in transitive dependencies may go undetected. Fix: Ensure Cargo.deny is properly configured with audit rules. Add a 'deny.toml' file at the repository root to actively scan for known vulnerabilities in dependencies.
• Medium · Disabled Debug Symbols in Release Build — Cargo.toml ([profile.release] section). The release profile has 'debug = false', which removes debug symbols. While this reduces binary size, it can hinder post-mortem security analysis and vulnerability debugging in production. Fix: Consider splitting configurations: keep 'debug = false' for size optimization, but maintain separate debug artifacts or symbol servers for security incident response and crash analysis.
• Low · LTO Configuration May Impact Binary Reproducibility — Cargo.toml ([profile.release] section). The release profile uses 'lto = "fat"' with 'codegen-units = 1', which can affect build reproducibility and increase build time significantly. While not directly a security issue, it impacts verification capabilities. Fix: Document the reproducible build process. Consider using 'lto = "thin"' for faster builds if acceptable. Maintain a published build hash/checksum for release artifacts for integrity verification.
• Low · Secret Backend Example Binary Exposed — Cargo.toml ([[bin]] section for secret-backend-example). The 'secret-backend-example' binary is compiled as part of the build. While feature-gated, the presence of example secret handling code in the binary could potentially expose patterns or sensitive implementation details. Fix: Ensure this example binary is only included in development/test builds. Use a dev-only feature flag and document security considerations for secret backend implementations.
• Low · Missing Security.md Policy Details — SECURITY.md. The SECURITY.md file provided is incomplete. The vulnerability reporting section is cut off, making it unclear what the actual vulnerability reporting process and SLA are. Fix: Complete and publish the full SECURITY.md with clear vulnerability reporting procedures, expected response times, supported versions, and responsible disclosure guidelines.
• Low · Unsigned Commits Not Enforced — .github/CODEOWNERS and branch protection configuration. While SECURITY.md mentions 'Signed Commits', the provided configuration does not show enforcement of commit signature verification on protected branches. Fix: Enable 'Require signed commits' on all protected branches (especially main/master) in GitHub branch protection rules to ensure code provenance.

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

What it runs against: a local clone of vectordotdev/vector — 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 vectordotdev/vector | Confirms the artifact applies here, not a fork | | 2 | License is still MPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch master 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 vectordotdev/vector. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/vectordotdev/vector.git
#   cd vector
#
# 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 vectordotdev/vector and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "src/config/loading/secret_backend_example.rs" \\
  && ok "src/config/loading/secret_backend_example.rs" \\
  || miss "missing critical file: src/config/loading/secret_backend_example.rs"
test -f ".github/workflows/test.yml" \\
  && ok ".github/workflows/test.yml" \\
  || miss "missing critical file: .github/workflows/test.yml"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"
test -f ".rustfmt.toml" \\
  && ok ".rustfmt.toml" \\
  || miss "missing critical file: .rustfmt.toml"

# 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/vectordotdev/vector"
  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.