sentry

packaged by Chainguard

Chainguard Container for sentry

Sentry is a developer-first error tracking and performance monitoring platform. This image runs the Sentry web service, task workers, schedulers, and consumers for self-hosted Sentry.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/sentry:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's sentry image is comparable to the upstream ghcr.io/getsentry/sentry image used by self-hosted Sentry. It keeps the upstream runtime layout: the sentry user (UID 999), the /usr/src/sentry working directory, the self-hosted configuration in /etc/sentry (SENTRY_CONF), the /data volume, and the python3 /docker_entrypoint.py run web entrypoint, which routes Sentry subcommands through tini.

The image differs from upstream in the following ways:

• The Python virtual environment lives at /usr/share/sentry/venv rather than /.venv, and its bin directory is first on PATH, so python3, sentry, and pip resolve as they do upstream.
• The image has no shell. Images that extend it with RUN steps, such as the self-hosted sentry/Dockerfile, must build from the -dev variant.
• The community sentry-kubernetes chart runs rm in the taskworker liveness probe and sh in the nodestore init container. Use the -dev variant for those containers, or override sentry.taskWorker.livenessProbe.
• The odiff image-diffing binary is not included, so the preprod snapshot image comparison feature is unavailable.

A complete self-hosted deployment also needs Snuba, Relay, Symbolicator, Vroom, the task broker, the uptime checker, Kafka, ClickHouse, PostgreSQL, Redis, and Memcached. Chainguard provides the Sentry components as the snuba, sentry-relay, symbolicator, sentry-vroom, sentry-taskbroker, sentry-uptime-checker, and sentry-launchpad images.

Prerequisites

Sentry needs a PostgreSQL database and a Redis server. The examples below use the postgres and redis Chainguard Containers.

Getting Started

Create a network and start PostgreSQL and Redis:

docker network create sentry
docker run -d --name sentry-postgres --network sentry \
  -e POSTGRES_USER=sentry -e POSTGRES_PASSWORD=sentry -e POSTGRES_DB=sentry \
  cgr.dev/chainguard/postgres:latest
docker run -d --name sentry-redis --network sentry cgr.dev/chainguard/redis:latest

The self-hosted configuration in /etc/sentry reads its backends from environment variables. Create an environment file that points Sentry at the two services:

cat > sentry.env <<EOF
SENTRY_POSTGRES_HOST=sentry-postgres
SENTRY_DB_NAME=sentry
SENTRY_DB_USER=sentry
SENTRY_DB_PASSWORD=sentry
SENTRY_REDIS_HOST=sentry-redis
SENTRY_SECRET_KEY=$(openssl rand -hex 32)
EOF

Run the database migrations and create an administrator account:

docker run --rm --network sentry --env-file sentry.env cgr.dev/ORGANIZATION/sentry:latest upgrade --noinput
docker run --rm --network sentry --env-file sentry.env cgr.dev/ORGANIZATION/sentry:latest \
  createuser --email admin@example.com --password 'change-me-please' --superuser --no-input

Start the web service and confirm it is healthy:

docker run -d --name sentry-web --network sentry -p 9000:9000 --env-file sentry.env cgr.dev/ORGANIZATION/sentry:latest
curl http://localhost:9000/_health/

ok

You can now sign in at http://localhost:9000 with the account you created. The same image runs the background services when you change the command, for example the task scheduler:

docker run -d --name sentry-scheduler --network sentry --env-file sentry.env \
  cgr.dev/ORGANIZATION/sentry:latest run taskworker-scheduler

To use this image with self-hosted Sentry, set SENTRY_IMAGE=cgr.dev/ORGANIZATION/sentry:latest-dev in its .env file before running ./install.sh. Self-hosted builds its own image on top of SENTRY_IMAGE with RUN steps, which need the shell in the -dev variant. The image includes update-ca-certificates, which the self-hosted entrypoint runs to load certificates from its certificates directory. The sentry-cleanup service installs cron with apt-get and does not build on this image.

Configuration

The image ships the self-hosted sentry.conf.py and config.yml in /etc/sentry. The SENTRY_* environment variables shown above cover the database and Redis; SENTRY_MEMCACHED_HOST and SENTRY_EMAIL_HOST configure Memcached and outgoing email the same way. For anything beyond that, mount your own configuration directory over /etc/sentry:

docker run -d --name sentry-web --network sentry -p 9000:9000 --env-file sentry.env \
  -v "$PWD/sentry-config:/etc/sentry:ro" \
  cgr.dev/ORGANIZATION/sentry:latest

Uploaded files, debug symbol caches, and release file caches are written to /data, which is owned by the sentry user. Mount a persistent volume there in production.

On Kubernetes, set enableServiceLinks: false in the pod spec when your PostgreSQL, Redis, Memcached, or SMTP Services are named sentry-postgres, sentry-redis, sentry-memcached, or sentry-email. Otherwise Kubernetes injects variables such as SENTRY_REDIS_PORT=tcp://... that override the ports sentry.conf.py reads.

Documentation and Resources

• Self-Hosted Sentry documentation
• Self-hosted Sentry repository
• Sentry source repository
• Chainguard Academy

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.