I'm running a self-hosted Sentry deployment on EKS with the community-maintained Kubernetes Helm chart. Because of budget constraints, the cluster currently uses only t3a.large nodes, and Sentry is running into memory bottlenecks across several components. The node group also hosts other workloads, so adding larger instance types is not currently practical. Has anyone optimized a similar setup? I'm looking for ways to reduce Sentry's resource consumption and operating cost, or guidance on whether moving to Sentry's managed service would be more practical.
4 Answers
The Kubernetes deployment can be surprisingly heavy for a small installation, especially when Kafka, ClickHouse, RabbitMQ, workers, and related services all run together. If you must stay on EKS, start by identifying the highest-memory components, reduce event retention, enable sampling, and disable features you do not use, such as profiling or replays. You can also review replica counts and JVM or service memory limits carefully, but avoid overcommitting a shared node group.
If the event volume is fairly low, managed Sentry may be cheaper overall once maintenance time, upgrades, monitoring, and incident troubleshooting are included. Self-hosting can make sense for strict data-control requirements or larger predictable workloads, but operating the full stack on shared t3a.large nodes is likely to remain fragile. Compare the managed-service cost with the infrastructure and engineering time required to keep the self-hosted deployment stable.
Self-hosted Sentry is difficult to run comfortably on small burstable nodes. Reducing retention, lowering ingestion through sampling, and turning off unused consumers can help, but there is a limit to how much you can save without affecting reliability. A dedicated node group also makes resource usage more predictable, even if the nodes are modest.
The challenge is primarily cost, so a dedicated pool may not be possible right now. That is why the managed service is also being considered.
For a small footprint, the Helm-based architecture may be more infrastructure than you need. The supported Docker Compose deployment is generally simpler and can run lighter because it avoids spreading as many services across Kubernetes. If EKS is mandatory, use a dedicated small node pool if possible and tune the deployment rather than letting Sentry compete with unrelated workloads.
The main consumers in this setup appear to be RabbitMQ, worker pods, ClickHouse, and related ingestion components, so profiling those first should make the biggest difference.