Skip to main content

Redacted Context MCP

Give coding agents useful local project context without exposing raw client names, people, email addresses, URLs, phone numbers, secrets, or meaningful filenames.

redacted-context-mcp is a read-only-by-default MCP server and CLI. It lets an agent search, navigate, and read useful content from a private local folder while replacing sensitive text and returning opaque file references.

Before redaction:

Client Example Lantern Labs uses production-db.internal.example
Contact avery@example.com about PROJECT-LANTERN-042.

Agent-visible result:

Client [ORG_a81f29d4a9c1e672540f68afc10d22c7] uses [DOMAIN_d12c88e1f730065c97d3f82f06d1188c].
Contact [EMAIL_711ae704108cd6e952dcb27f0d6e999a] about [SENSITIVE_45f80ab22bc94e105a93aa830c7d3b9c].

The placeholder values above are illustrative. Real values are deterministic for one local vault salt and will differ.

Quick Start

Python 3.11 or newer is required. Install the commands with pipx, then use a local Ollama model to draft the project-specific redaction terms:

pipx install redacted-context-mcp
ollama pull gemma4:e4b
redctx --root ~/private-context discover \
  --model gemma4:e4b \
  --output .agent-context-redactor.toml

Review the generated .agent-context-redactor.toml because it intentionally contains the raw names and terms that should be hidden. Then audit the setup and start the stdio MCP server:

redctx --root ~/private-context audit
redctx-mcp --root ~/private-context

Discovery is explicit: audit does not call a model or generate this config. Without an explicit config, the built-in detectors still cover common emails, URLs, phone numbers, domains, secrets, and some names, but project-specific client names and codenames may be missed. To avoid Ollama, create the config manually using the Local Redaction Config example.

The server waits for an MCP client on standard input; press Ctrl-C if you start it directly in a terminal. For a no-credentials walkthrough using fictional data, see the self-contained quick-start demo.

Claude Code MCP Configuration

Claude Code is one of the clients already supported by this repository. Put the following in the agent workspace's .mcp.json, replacing the root with an absolute path to the private context folder:

{
  "mcpServers": {
    "redacted_context": {
      "type": "stdio",
      "command": "redctx-mcp",
      "args": [
        "--root",
        "/absolute/path/to/private-context"
      ]
    }
  }
}

The same installed redctx-mcp command can be used with the Codex and generic stdio configurations documented below.

Security Boundary

This project provides practical privacy guardrails, not guaranteed anonymization, sandboxing, cryptographic isolation, complete DLP, or perfect prevention of metadata leakage. File sizes, line counts, and timing remain possible metadata side channels.

The protection can be bypassed if the coding agent can also read the unredacted source directory through shell commands or other filesystem tools. For hard enforcement, run the agent as a separate OS user or in a container that cannot access that directory directly, and expose only the MCP server or a separate redaction service.

Read SECURITY.md for the threat model and SECURITY_INVARIANTS.md for the behavior the test suite is intended to preserve.

The core workflow is:

agent workspace
  -> redacted MCP tools
    -> private source folder
      -> redacted output with opaque @p_<id> file references

Features

  • Dual-era MCP stdio server supporting stateless 2026-07-28 clients and legacy initialization-based clients through 2025-11-25.
  • Redacted MCP resources using redctx://p_<id> URIs.
  • Optional MCP redctx_submit_doc tool for controlled writes of generated redacted documents back into a configured private-root subdirectory.
  • CLI fallback with the same redaction behavior.
  • Local-salted opaque stable path ids such as @p_1a2b3c4d5e6f.
  • Deterministic 128-bit HMAC placeholders such as [PERSON_1a2b3c4d5e6f7890a1b2c3d4e5f60718].
  • Bounded operation budgets for traversals, reads, bundles, searches, audits, benchmarks, discovery samples, MCP resource listing/reads, and controlled write rehydration scans.
  • Redacted tree, list, read, search, stat, bundle, audit, and benchmark operations.
  • CLI-only rehydrate command for restoring redacted exports locally from the private source root.
  • Local ignored redaction config for exact client, person, organization, and project terms.
  • Optional local-LLM discovery command to draft that config from private files without sending content to Claude or a hosted model.
  • No runtime Python dependencies.
  • Optional local DOCX, PPTX, PDF, XLSX, and XLS extraction using Microsoft MarkItDown.
  • Ranked multi-word passage retrieval with opaque references and line citations.
  • Works well with a neutral agent workspace that does not contain raw context files.

Who This Is For

Use this when you want an agent to reason over a private local folder without handing the model the raw names and identifiers in that folder.

Good fits:

  • consulting or client delivery knowledgebases;
  • internal project notes, stakeholder notes, and transcripts;
  • architecture or governance documentation with private names mixed in;
  • private GitHub issues that should be summarized through neutral aliases.

Do not treat this as a formal anonymization or data-loss-prevention system.

Installation Options

The recommended installation method is pipx:

pipx install redacted-context-mcp

Regular pip installation is also supported:

python -m pip install redacted-context-mcp

Install from a source checkout only for development or to test an unreleased version:

python -m pip install -e .

This installs two console commands:

redctx      # CLI
redctx-mcp  # MCP stdio server

For redctx discover, install Ollama separately and pull a local model such as gemma4:e4b. The core redacted CLI and MCP server do not require Ollama.

Model tags must match Ollama exactly. Check installed tags with ollama list and pass the full value shown in the NAME column to --model.

Use two sibling folders under a neutral parent:

/work/
  agent-workdir/    # Claude Code starts here; no raw context files
  source-private/   # private project/context repository

The agent starts in agent-workdir/. The MCP server reads source-private/, redacts output, and returns only redacted text.

Keep the private folder outside the active agent workspace when possible. If the agent can still run shell commands against the raw private folder, the MCP redaction layer is only an instruction-level guardrail, not a hard boundary.

Claude Code MCP Config

If redctx-mcp is installed, put this in agent-workdir/.mcp.json:

{
  "mcpServers": {
    "redacted_context": {
      "type": "stdio",
      "command": "redctx-mcp",
      "args": [
        "--root",
        "../source-private"
      ]
    }
  }
}

If running directly from a source checkout without installing:

{
  "mcpServers": {
    "redacted_context": {
      "type": "stdio",
      "command": "python3",
      "args": [
        "../redacted-context-mcp/src/redacted_context_mcp/server.py",
        "--root",
        "../source-private"
      ]
    }
  }
}

Then start Claude Code from the agent workspace:

cd /work/agent-workdir
claude

If Claude Code was already running, restart it or reconnect MCP servers with /mcp.

For persistent Claude Code guidance, copy examples/agent-CLAUDE.md into agent-workdir/CLAUDE.md.

Codex MCP Config

Codex supports local stdio MCP servers through config.toml. Put this in ~/.codex/config.toml, or in agent-workdir/.codex/config.toml for a trusted project-scoped setup:

[mcp_servers.redacted_context]
command = "redctx-mcp"
args = ["--root", "../source-private"]
enabled = true
required = true

If running directly from a source checkout without installing:

[mcp_servers.redacted_context]
command = "python3"
args = [
  "../redacted-context-mcp/src/redacted_context_mcp/server.py",
  "--root",
  "../source-private",
]
enabled = true
required = true

For persistent Codex guidance, copy examples/agent-AGENTS.md into agent-workdir/AGENTS.md. Codex reads AGENTS.md when a session starts, so restart Codex after adding or changing it.

Generic MCP Clients

Any MCP client that can launch a stdio server can run:

redctx-mcp --root /absolute/path/to/source-private

Use the client-specific configuration format to pass that command and args. The server advertises instructions and exposes only redacted redctx_* tools. Modern clients can use the stateless MCP 2026-07-28 flow with per-request metadata and server/discover; legacy clients continue to negotiate through initialize.

MCP Tools

The server exposes:

  • redctx_tree — show a redacted file tree with opaque ids
  • redctx_list — list redacted directory entries
  • redctx_read — read redacted file contents by path or @p_<id>
  • redctx_search — search redacted text
  • redctx_retrieve — retrieve relevant passages ranked by keyword coverage and relevance
  • redctx_stat — inspect redacted metadata
  • redctx_bundle — concatenate redacted context files
  • redctx_doctor — show config counts without sensitive terms
  • redctx_audit — run local containment and redaction checks
  • redctx_refresh_index — refresh the in-memory opaque path index

Agents should carry @p_<id> references between calls rather than using raw filenames.

The MCP server also exposes redacted text files as resources:

  • resources/list returns redctx://p_<id> resource URIs with redacted titles.
  • resources/read returns redacted file text for those opaque resource URIs.

Controlled MCP Writes

By default, the MCP server exposes only read-only tools. To let an agent submit new redacted documents back into the private source root, start the server with an explicit write subdirectory:

redctx-mcp --root ../source-private --enable-writes --write-subdir incoming

This adds redctx_submit_doc. The tool accepts a relative target_path, redacted text, and optional overwrite. The server rehydrates known placeholders locally, rejects unresolved redaction tokens, and writes only under the configured write subdirectory. Tool responses use redacted paths and opaque ids; they do not return the raw restored path.

CLI Fallback

The CLI is useful for smoke tests or clients without MCP:

redctx --root ../source-private doctor
redctx --root ../source-private tree context --max-depth 2
redctx --root ../source-private search "governance" context --ignore-case --context 2
redctx --root ../source-private read @p_1a2b3c4d5e6f --start-line 1 --end-line 80
redctx --root ../source-private bundle context --glob "*.md" --max-files 10
redctx --root ../source-private audit --format json
redctx --root ../source-private benchmark --format json

Ranked Retrieval

Use retrieve when you want relevant passages for several keywords, even when the words appear in a different order or on different lines:

redctx --root ../source-private retrieve "database backup recovery" \
  --max-results 8 --max-chars 12000

The MCP equivalent is redctx_retrieve with query, optional paths and glob, max_results, and max_chars. Each result includes an opaque file reference and a line range that can be passed to redctx_read for more context. Passages covering more query terms rank first, then BM25 keyword relevance; matching is case-insensitive and ignores a small set of common English words. Existing literal and regex search behavior is unchanged.

Only redacted text is tokenized and scored. Complete placeholders can be used as search terms. Retrieval keeps no persistent index, makes no model calls, and has no additional dependencies. Results contain complete passages within the character budget; if none fits, increase max_chars. A limit notice marks omitted matches. Scan limits fail the request instead of presenting a partial scan as a complete ranking. Narrow paths or glob for large knowledgebases.

Optional Document Extraction

Install the optional Microsoft MarkItDown integration and enable it explicitly for the CLI or MCP server:

python -m pip install 'redacted-context-mcp[documents]'
redctx --root ../source-private --documents retrieve "database backup recovery"
redctx --root ../source-private --documents read @p_1a2b3c4d5e6f
redctx-mcp --root ../source-private --documents

For pipx, install with pipx install 'redacted-context-mcp[documents]', or add the dependencies to an existing installation with pipx inject redacted-context-mcp 'markitdown[docx,pptx,pdf,xlsx,xls]>=0.1.7,<0.2'. For an MCP client configuration, add --documents to the server's args.

Supported formats are DOCX, PPTX, PDF, XLSX, and XLS. They become available through read/head/tail, search, retrieve, bundle, local discovery, rehydration source scans, and MCP resources. Conversion produces local Markdown, then the same redactor processes it. Line citations refer to extracted Markdown lines, not PDF pages or slide numbers. The extractor does not reproduce document layout or evaluate spreadsheet formulas.

The plain installation stays dependency-free. Installing the extra alone does not change which files are exposed; --documents removes only the built-in exclusions for supported formats. Configured exclusions and never-serve paths still apply. Each document is read through the existing containment checks and converted in a short-lived local worker with a 15-second deadline, 5 MB input cap, 1 million extracted-character cap, and OOXML expansion limits (50 MB and 2,000 ZIP members). Existing operation budgets also apply. No raw converted Markdown is persisted; the MCP resource cache holds redacted text only.

Only the selected format converter is invoked on local bytes. URL fetching, plugins, cloud conversion, audio transcription, and LLM/OCR clients are not enabled. Legacy .doc and .ppt files must be exported to a supported format. Scanned PDFs need OCR outside this MCP; an empty extraction produces a clear error. Encrypted, malformed, or oversized documents fail with non-sensitive errors. Conversion is an additional parser surface, not a hard sandbox; use the isolation described in Security Boundary for untrusted source files.

Local Rehydration

The rehydrate command restores redacted text by scanning the private source root with the same salt and config, rebuilding the placeholder map, and applying it to a redacted file or folder. This emits raw private text, so it is CLI-only and requires an explicit acknowledgement flag.

redctx --root ../source-private rehydrate ./redacted-output.md --allow-raw-output > raw-output.md
redctx --root ../source-private rehydrate ./redacted-folder \
  --output ./raw-folder \
  --allow-raw-output

Rehydration is not cryptographic reversal. A redacted file alone is not enough; the command needs access to the original private root or equivalent local source material to rebuild the mapping.

Local Redaction Config

Create .agent-context-redactor.toml in the private source root. This file is ignored by the example .gitignore because it may contain exact sensitive terms.

[redaction]
salt = "local-random-string-kept-private"
clients = ["Client Legal Name", "Client Acronym"]
organizations = ["Supplier Name", "Partner Company"]
people = ["Person One", "Person Two"]
terms = ["project codename", "internal programme name"]
allow = ["Azure", "PostgreSQL", "Kubernetes"]
term_files = ["private-redaction-terms.txt"]

[github.repos.context]
owner = "private-org-or-user"
repo = "private-context-repo"
token_env = "GITHUB_TOKEN"

The tool also derives likely aliases from the private source folder name and accepts additional comma- or newline-separated terms through REDACTED_CONTEXT_TERMS.

The optional salt controls opaque path ids and deterministic placeholders. If omitted, redctx creates or reuses a random 256-bit vault salt in user-local state. Empty, malformed, or root-contained salt state fails closed instead of silently rotating aliases. You can also set REDACTED_CONTEXT_SALT in the environment that starts redctx or redctx-mcp. redctx doctor reports whether the active salt came from local state, config, or environment.

GitHub repo entries are optional. Use neutral aliases such as context; agents use the alias, while the real owner/repo stays in this local config. Private repos require the named token environment variable in the shell that starts redctx or redctx-mcp.

Updating Rules During an MCP Session

The MCP server automatically checks the local config and its referenced term_files before each tool call or resource list/read. Save your reviewed rules and retry the request: new terms, exclusions, allow-list changes, and detector profiles take effect without reconnecting. This also picks up config updates written by discover-update.

For example, adding a project codename to terms causes the next read of an already cached document to redact that codename. Successful policy changes clear the redacted resource cache, path index, and old rehydration mappings. Opaque path references and placeholders for unchanged terms remain stable as long as the salt and applicable redaction category stay the same.

If the config is invalid or unreadable, or a previously loaded config or still-referenced term file disappears, context requests fail closed with a non-sensitive error. Repair the file and retry; the server recovers without a restart. Referenced term files remain optional until first loaded and are watched for creation. To deliberately stop using a term file, remove its term_files entry.

Salt changes require a server restart and fresh opaque references; requests are blocked until restart or restoration of the original salt. Changes to the launch environment, server flags, or external vault-salt state also require a restart. Reload checks use file metadata at request boundaries; they do not retract previously returned content or provide protection against adversarial concurrent filesystem changes.

Redacted GitHub Issues

Configured GitHub issues can be read through the same redaction layer:

export GITHUB_TOKEN="<github-token>"
redctx --root ../source-private github repos
redctx --root ../source-private github issues context --state open --limit 20
redctx --root ../source-private github issue context 123 --comments
redctx --root ../source-private github search context "policy controls"

The MCP server exposes the same flow with:

  • redctx_github_repos
  • redctx_github_list_issues
  • redctx_github_read_issue
  • redctx_github_search_issues

Outputs redact titles, bodies, labels, and comments, and mark GitHub text as untrusted external content. Raw author logins and raw GitHub URLs are not printed; authors are shown as stable per-vault, per-repo opaque ids.

Discover Terms With A Local LLM

redctx discover can draft .agent-context-redactor.toml using a local Ollama model. This is a human setup command, not an MCP tool, because its output intentionally contains the raw names you want to redact.

Example with a small local model:

ollama pull gemma4:e4b
redctx --root ../source-private discover context progress archive \
  --model gemma4:e4b \
  --glob "*.md" \
  --output .agent-context-redactor.toml

If you switch models, use the exact tag from ollama list.

Review the generated file before use. To avoid overwriting an existing config, the command refuses to write over --output unless --force is passed.

Discovery output is post-processed with generic cleanup rules. The cleanup does not include project-specific names; it only:

  • omits public/default-allowed terms that the redactor already allows;
  • moves other likely tool/package names to allow;
  • drops obvious filenames, meeting/ticket IDs, country-only values, job titles, and generic workflow/process labels;
  • strips role notes from full names such as Alice Example (CIO);
  • ignores single first names by default because they over-redact.

Use --raw-discovery if you want the local model's categories with only basic dedupe.

Useful options:

redctx --root ../source-private discover --help
redctx --root ../source-private discover context --format json
redctx --root ../source-private discover context --raw-discovery
redctx --root ../source-private discover context --max-files 20 --max-chars-per-file 8000
redctx --root ../source-private discover context --endpoint http://localhost:11434

The command uses Ollama's local /api/generate endpoint with streaming disabled and JSON output requested. No hosted LLM is called by this feature. Non-loopback plain-http endpoints are refused unless you pass --allow-remote-endpoint, because discovery payloads contain raw private text.

Automate Incremental Config Updates

Repository hooks can classify exact staged Git blobs without duplicating the MCP's discovery and merge policy. Supply one JSON object per line:

{"path":"private/meeting.md","text":"raw staged document text","sha256":"optional-source-digest"}

Then call the hook-facing CLI:

redctx --root ../source-private discover-update \
  --input-jsonl /tmp/staged-documents.jsonl \
  --seed-config config/redaction-seed.toml \
  --output-config .agent-context-redactor.toml \
  --model gemma4:e4b

discover-update sends each complete document to the configured local Ollama endpoint in a separate request. It rejects model values that are not exact substrings of that document, monotonically adds sensitive terms, keeps reviewed seed policy settings authoritative, preserves unrelated TOML tables and comments, and writes atomically. By default, model output cannot expand the allow-list.

Documents are never silently truncated. A document over --max-chars-per-document, or an input set over --max-total-chars, fails before the model is called. Set those limits to fit the selected model's actual context window. --merge-only applies a reviewed seed change without reading documents or calling Ollama.

The equivalent Python composition API is:

from redacted_context_mcp import (
    DiscoveryDocument,
    build_discovery_update,
    discover_documents,
    write_discovery_update,
)
from redacted_context_mcp.discovery import OllamaDiscoveryClient

documents = [DiscoveryDocument(path="private/meeting.md", text=raw_text)]
client = OllamaDiscoveryClient(
    endpoint="http://127.0.0.1:11434",
    model="gemma4:e4b",
    timeout=120,
)
discovery = discover_documents(documents, client=client)
update = build_discovery_update(existing_toml, discovery, seed_text=seed_toml)
write_discovery_update(config_path, update)

Both interfaces intentionally handle raw private text and raw discovered names. Keep them local and outside an agent's accessible workspace. This feature reduces what a separate coding model receives; it is not encryption, DLP, or a proof that the local model found every sensitive entity.

Claude Code Permissions

MCP routing is the main workflow. Claude Code permissions can add guardrails by denying direct reads/searches into the private source folder and allowing only the redacted MCP tools. See examples/claude-settings.example.json.

Security Model

This project is a practical privacy guardrail, not a formal de-identification system.

It helps because:

  • the agent starts in a neutral folder with no raw context files;
  • the useful operations are exposed as redacted MCP tools;
  • filenames can be navigated through opaque ids;
  • raw names, emails, URLs, phones, and configured terms are redacted.

The rehydrate command intentionally reverses redacted exports for the local operator. redctx_submit_doc can also rehydrate generated redacted text, but only when MCP writes are explicitly enabled and only into the configured write subdirectory. Submitted content is verified to redact consistently on read-back, and the write subdirectory itself is never used as a rehydration source. Do not run rehydration workflows from an agent workspace where the model can read raw output.

Additional guardrails:

  • The redaction config (default or explicit --config), configured term files, .env*, *.key, *.pem, and *.crt files are never served through redacted tools, even with --include-private, with case-folded matching so .ENV and server.PEM variants are refused too.
  • Bare long hex strings (the vault-salt shape), salt-keyed assignments, and underscore-qualified secrets such as DB_PASSWORD=... are redacted by default.
  • MCP searches enforce an operation deadline, and user-supplied regexes are matched in an isolated, killable child process after a fast-fail screen for catastrophic-backtracking patterns, so a crafted regex cannot hang the server.
  • redctx discover refuses non-loopback plain-http Ollama endpoints unless --allow-remote-endpoint acknowledges the exposure.
  • Placeholders are deterministic HMACs over the vault salt. Keep the salt in the local config or user-local state; REDACTED_CONTEXT_SALT can be visible in process environments, and anyone holding the salt can verify dictionary guesses against placeholders.

It is not a hard security boundary if the agent process runs as the same OS user that can read the private source folder. For hard enforcement, run the agent as a separate OS user or container without filesystem access to the private source folder, and expose only the MCP server or a separate redaction service.

Development

See ARCHITECTURE.md for the design boundaries and CONTRIBUTING.md for local development and release checks.

PYTHONPATH=src python3 -m unittest discover -s tests -p 'test_*.py'
python3 -m py_compile src/redacted_context_mcp/core.py src/redacted_context_mcp/server.py

License

MIT.

Metadata

Release files for redacted-context-mcp 0.8.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for redacted-context-mcp 0.8.0
File Size Uploaded Provenance
redacted_context_mcp-0.8.0.tar.gz 118.5 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for redacted-context-mcp 0.8.0
File Interpreter ABI Platform
redacted_context_mcp-0.8.0-py3-none-any.whl Python 3 none any Details

Total release size: 198.1 kB

Release files / redacted_context_mcp-0.8.0.tar.gz

Download URL redacted_context_mcp-0.8.0.tar.gz
Size 118.5 kB
Tags Source
SHA-256 checksum
How to use checksums
eed56a99517578ab78f1304276791e2de075f9aff58a6b0b4a78f8fc583d7261
BLAKE2b-256 checksum
How to use checksums
89d581691398750ed9092868eb2730bdaf6512109b8af08c02add9c5dce43337
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.

Transparency log

Release files / redacted_context_mcp-0.8.0-py3-none-any.whl

Download URL redacted_context_mcp-0.8.0-py3-none-any.whl
Size 79.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
fab3f5324ab2da11d5aff6924d5e912cb30631890beb80e07c3466d7564989e9
BLAKE2b-256 checksum
How to use checksums
ad9c43312bedd136dc8202cc264c9e8e5aa43f507249e08752fc9c24ce03b6d6
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.

Transparency log

Security for redacted-context-mcp 0.8.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for redacted_context_mcp-0.8.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 12, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page