$ show getsentry/self-hosted
This repository is Sentry's self-hosted packaging and operations layer, not the Sentry application itself. It bundles upstream Sentry, Relay, Snuba, Symbolicator, Taskbroker, Vroom, uptime-checker, and launchpad images into a large Docker Compose deployment, and provides idempotent install/upgrade scripts, generated config templates, healthchecks, backup/restore tooling, and optional community patches. The primary entry points are install.sh, which sources a sequence of modular install/ steps, plus operator scripts under scripts/ (reset.sh, backup.sh, restore.sh), sentry-admin.sh for Django admin commands, and a reusable GitHub Action (action.yaml) that downstream Sentry repos use to run self-hosted end-to-end tests against their own images. The runtime architecture is a compose stack: nginx terminates HTTP and routes ingestion to Relay, which validates and buffers events before writing to Kafka; Snuba consumer containers move data from Kafka into ClickHouse; Sentry web and consumer containers read from Kafka/Postgres/Redis and the SeaweedFS S3-compatible object store; Symbolicator handles native symbolication; Taskbroker routes async tasks. The compose file supports an errors-only profile that dramatically reduces the service count and a feature-complete profile that enables transactions, metrics, replays, profiling, uptime, logs, and mobile builds. The codebase is notably well-tested for an infrastructure repo, with bash unit tests under _unit-test/ and pytest integration tests under _integration-test/ that install the full stack and verify event ingestion end to end. Maintenance is active and dependency drift is low: images are bumped regularly via Dependabot, shell scripts are linted with ShellCheck and formatted with shfmt, there is a pre-commit pipeline, and the repo tracks recent upstream replacements such as Valkey for Redis, pgbouncer, taskbroker, and ClickHouse upgrades. The main limitation for reuse is that most of the repository is configuration and deployment glue tied to this specific stack; the few genuinely self-contained, extractable components are small utilities around healthchecks, cryptography/migration, and cron containers.
The LLM identified 4 files worth highlighting for reuse:
Self-contained Python CLI that recovers a SeaweedFS filer encryption key from either plaintext hex or wrapped v1/v2 envelope formats. Uses HKDF-SHA256 and AES-GCM with careful handling of truncated input, wrong passphrases, and legacy salt values. It is unit-tested via _integration-test/test_seaweedfs_kek.py and can be extracted into any project needing encrypted-key recovery or migration of wrapped storage keys.
Minimal, dependency-free HTTP healthcheck that uses only Python standard library, bypasses injected HTTP(S)_PROXY, and emits concise one-line errors instead of tracebacks so docker inspect output stays readable. It requires only python3 on PATH, making it usable across distroless and minimal images. This is a cleanly reusable building block for any container healthcheck.
A feature-flagged installer step that builds per-service CA trust stores by copying the baseline /etc/ssl/certs from each upstream image with docker create/cp, overlaying user-provided .crt files, regenerating the bundle, and running openssl rehash. It is idempotent, validates certificates, and emits a ready-to-paste docker-compose.override.yml fragment. The technique is reusable for injecting custom CAs into arbitrary multi-container deployments, though the script itself is coupled to this repo's service list and env vars.
A small entrypoint that runs arbitrary cron jobs inside a Docker container while preserving runtime environment variables via /container.env and BASH_ENV. It renders each job with SHELL=/bin/bash, sends job output to stdout/stderr, and execs cron in the foreground. This is a clean, reusable pattern for packaging scheduled maintenance jobs in containers without losing environment context.