Compare commits

...

1 Commits

Author SHA1 Message Date
Oclick021 ea638c0eae Document Sentry self-hosted deployment 2026-07-08 15:31:21 +03:30
11 changed files with 491 additions and 128 deletions
+29
View File
@@ -22,6 +22,7 @@ Monitoring, alerting, automated backups and restore validation are now productio
| Jitsi Meet | https://meet.silveressence.net |
| BaGet | https://nuget.silveressence.net |
| DbGate | https://dbgate.silveressence.net |
| Sentry | https://sentry.silveressence.net |
| Nextcloud | https://cloud.silveressence.net |
| Xray | Public tunneling endpoint |
@@ -288,6 +289,34 @@ Status:
---
### Sentry
Purpose:
* Centralized error tracking
* Application exception diagnostics
* Release health and performance visibility
Access:
* https://sentry.silveressence.net
* HTTPS through Nginx Proxy Manager
Deployment:
* Installed with upstream Sentry self-hosted `install.sh`
* Compose project `sentry-self-hosted`
* Install directory `/srv/docker/sentry`
* Public entry container `sentry-self-hosted-nginx-1`
* Nginx Proxy Manager forwards to `sentry-self-hosted-nginx-1:80`
* Exception to the normal `slcompose` and Infisical service pattern
Status:
* Operational
---
### Xray
Purpose:
+3
View File
@@ -108,6 +108,8 @@ MSSQL is attached only to `internal`. DbGate is attached to both `internal` and
Nextcloud is attached to `proxy` and `nextcloud_nextcloud_internal`. Its PostgreSQL and Redis containers are attached only to `nextcloud_nextcloud_internal`.
Sentry was installed using the upstream self-hosted `install.sh` workflow in `/srv/docker/sentry`, is available at `sentry.silveressence.net`, and uses the `sentry-self-hosted_default` network for internal services. Nginx Proxy Manager forwards to `sentry-self-hosted-nginx-1:80`. It is not a normal `slcompose` service.
Jitsi uses `jitsi-docker-jitsi-meet-aa76415_meet.jitsi` for its internal cluster and `proxy` for web access. Xray is currently attached to `proxy`; `xray_default` exists but had no running containers attached in the 2026-06-24 runtime snapshot.
## Authentication
@@ -241,3 +243,4 @@ docs/roadmap.md
* Xray introduced as a tunneling and connectivity layer
* Multi-network segmentation formalized: internal, proxy and isolated infrastructure networks
* Nextcloud deployed as the private cloud storage service at cloud.silveressence.net
* Sentry deployed using upstream self-hosted install.sh and exposed at sentry.silveressence.net
+44
View File
@@ -241,6 +241,47 @@ The 2026-07-08 runtime snapshot verified `nextcloud_nextcloud_data` and `nextclo
---
#### Sentry
Deployment model:
```text
Upstream Sentry self-hosted install.sh
```
Contains:
* `/srv/docker/sentry`
* Generated Sentry configuration
* PostgreSQL metadata
* ClickHouse event data
* Redis cache and coordination data
* Kafka data if persistence is enabled
* SeaweedFS attachments and object storage
Required:
* Backup of `/srv/docker/sentry`
* Backup of Sentry generated config and secret files
* Backup of persistent Sentry Docker volumes
* Nginx Proxy Manager route and certificate state for `sentry.silveressence.net`
Importance:
Critical
Sentry is not a normal SilverLinux `slcompose` service. Preserve its upstream self-hosted installer layout and restore it as one deployment unit.
Verified configuration files:
```text
/srv/docker/sentry/.env
/srv/docker/sentry/docker-compose.yml
/srv/docker/sentry/sentry/sentry.conf.py
```
---
#### Nginx Proxy Manager
Locations:
@@ -526,6 +567,7 @@ Restore order:
11. DbGate
12. Xray
13. Nextcloud
14. Sentry
---
@@ -550,6 +592,8 @@ Verified:
Nextcloud restore validation is pending after its 2026-07-08 operational documentation update.
Sentry restore validation is pending after its upstream `install.sh` deployment documentation update.
Validation results:
* MSSQL backup integrity verified
+28
View File
@@ -625,6 +625,34 @@ Implemented
---
## 2026-07-08 - Document Sentry As Upstream Self-Hosted Deployment
Decision:
Run Sentry using the upstream self-hosted `install.sh` workflow and expose it at `sentry.silveressence.net` through Nginx Proxy Manager.
Implementation:
* Use the upstream Sentry self-hosted installer layout.
* Treat `sentry-self-hosted` as one atomic deployment unit.
* Keep Sentry backing services isolated on `sentry-self-hosted_default`.
* Route public access through the Sentry nginx or web entry layer.
* Do not force Sentry into the standard SilverLinux `slcompose` and Infisical pattern.
Reason:
* Sentry is a large distributed application with many tightly coupled services.
* The upstream self-hosted installer manages required configuration and generated secrets.
* Preserving the upstream layout reduces maintenance risk during upgrades.
Status:
```text
Implemented
```
---
## Future Decisions
Document future decisions using the following template:
+41 -1
View File
@@ -9,7 +9,7 @@ All public services are routed through Nginx Proxy Manager.
Verified proxy-host snapshot:
```text
2026-06-24, with Nextcloud evidence added from 2026-07-08 server output
2026-06-24, with Nextcloud and Sentry evidence added from 2026-07-08 server output
```
---
@@ -38,6 +38,7 @@ Used for:
| 5 | `team.silveressence.net` | `http://openproject:80` | enabled | enabled | disabled | enabled | none | enabled |
| 6 | `nuget.silveressence.net` | `http://baget:80` | disabled | disabled | disabled | disabled | none | enabled |
| 8 | `dbgate.silveressence.net` | `http://dbgate:3000` | disabled | disabled | disabled | enabled | none | enabled |
| 12 | `sentry.silveressence.net` | `http://sentry-self-hosted-nginx-1:80` | enabled | enabled | disabled | enabled | none | enabled |
| 13 | `cloud.silveressence.net` | `http://nextcloud:80` | disabled | disabled | disabled | enabled | none | enabled |
All listed active inventory hosts have Block Exploits enabled.
@@ -73,6 +74,7 @@ Nginx Proxy Manager findings from the 2026-06-24 snapshot:
* `portainer.silveressence.net` has SSL Force, HTTP/2 and HSTS enabled.
* `team.silveressence.net` has SSL Force and HTTP/2 enabled.
* `sentry.silveressence.net` has SSL Force, HTTP/2, WebSocket and Block Exploits enabled; HSTS is disabled.
* `git.silveressence.net`, `meet.silveressence.net`, `nuget.silveressence.net`, `dbgate.silveressence.net` and `cloud.silveressence.net` do not have SSL Force enabled.
* No listed proxy host uses an Nginx Proxy Manager access list.
* DbGate is a high-sensitivity database administration interface and should be prioritized for SSL Force and an access restriction policy.
@@ -319,6 +321,44 @@ Active
---
### Sentry
Domain:
```text
sentry.silveressence.net
```
Purpose:
* Error tracking and observability
* Event ingestion endpoint
* Sentry web UI
Container:
```text
sentry-self-hosted-nginx-1
```
Routing:
```text
Nginx Proxy Manager -> sentry-self-hosted-nginx-1:80
```
Status:
```text
Active
```
Runtime note:
Sentry was installed through the upstream self-hosted `install.sh` and is available at `https://sentry.silveressence.net`. Nginx Proxy Manager proxy host 12 forwards the domain to `http://sentry-self-hosted-nginx-1:80`. The 2026-07-08 database query showed SSL Force enabled, HTTP/2 enabled, HSTS disabled, HSTS subdomains disabled, WebSocket enabled, Block Exploits enabled and no access list.
---
### Nextcloud
Domain:
+44 -2
View File
@@ -8,12 +8,12 @@ Current model:
* `internal` for private databases and backend service traffic
* `proxy` for HTTP and HTTPS services routed by Nginx Proxy Manager
* Isolated stack networks for specialized infrastructure such as Jitsi, Xray, monitoring and CI/CD runners
* Isolated stack networks for specialized infrastructure such as Jitsi, Xray, monitoring, Sentry and CI/CD runners
Verified runtime snapshot:
```text
2026-06-24 10:15 CEST, with Nextcloud evidence added from 2026-07-08 13:21:13 +02:00
2026-06-24 10:15 CEST, with Nextcloud and Sentry evidence added from 2026-07-08 server output
```
---
@@ -74,6 +74,7 @@ Public services:
* Jitsi Web
* BaGet
* Nextcloud
* Sentry
Internal monitoring services:
@@ -111,6 +112,7 @@ jitsi-docker-jitsi-meet-aa76415_meet.jitsi
xray_default
gitea-runner_default
monitoring stack network
sentry-self-hosted_default
```
#### jitsi-docker-jitsi-meet-aa76415_meet.jitsi
@@ -248,6 +250,35 @@ Verified subnet:
172.27.0.0/16
```
#### sentry-self-hosted_default
Purpose:
* Internal Sentry event processing, storage and worker communication
* Keep Sentry backing services isolated from shared application networks
Services:
* Sentry web, relay, worker, cron and consumer services
* Kafka
* Snuba
* ClickHouse
* PostgreSQL
* Redis
* SeaweedFS
Public attachment:
* Public access is through Nginx Proxy Manager at `sentry.silveressence.net`.
* The public entry container is `sentry-self-hosted-nginx-1`.
* Sentry databases, queues and workers must remain internal to the Sentry deployment.
Verified subnet:
```text
172.25.0.0/16
```
---
## Runtime-Published Ports
@@ -263,6 +294,7 @@ The current Docker runtime includes these host-published ports.
| Jitsi Web | `8000`, `8443` | `80`, `443` | `8443` allowed; `8000` not listed | Direct HTTP and HTTPS ports also published |
| Jitsi JVB | `10000/udp` | `10000/udp` | Allowed | Required media bridge traffic |
| Xray | `32443` | `8080` | Allowed | Public tunneling endpoint |
| Sentry nginx | `9000` | `80` | Not listed as allowed | Nginx Proxy Manager forwards to `sentry-self-hosted-nginx-1:80`; direct host port should be reviewed |
Nextcloud runtime exposure from the 2026-07-08 snapshot:
@@ -283,6 +315,12 @@ Database ports:
* MSSQL exposes `1433/tcp` only inside Docker.
* DbGate exposes `3000/tcp` only inside Docker.
Sentry runtime exposure:
* `sentry.silveressence.net` is routed through Nginx Proxy Manager to `sentry-self-hosted-nginx-1:80`.
* `sentry-self-hosted-nginx-1` publishes `0.0.0.0:9000 -> 80/tcp`.
* Sentry backing services should not publish host ports.
---
## Topology Summary
@@ -299,6 +337,7 @@ Internet
-> Jitsi Web
-> BaGet
-> Nextcloud
-> Sentry
internal network
-> PostgreSQL
@@ -311,6 +350,7 @@ isolated networks
-> gitea-runner_default
-> monitoring stack network
-> nextcloud_nextcloud_internal
-> sentry-self-hosted_default
```
---
@@ -341,10 +381,12 @@ Periodically verify:
* Jitsi internal components remain attached to `jitsi-docker-jitsi-meet-aa76415_meet.jitsi`
* The desired Xray attachment is reconciled with the fact that `xray_default` currently has no running containers
* Direct host-published ports are intentional and protected by firewall policy
* Sentry host-published port `9000` has a documented owner and firewall policy
* UFW-only allowed ports have documented owners
* Prometheus targets remain healthy
* Grafana datasource connection remains healthy
* Nextcloud remains routed through Nginx Proxy Manager without host-published database or Redis ports
* Sentry remains routed through Nginx Proxy Manager with internal backing services isolated
* Unused Docker networks are removed only after confirming they are not active dependencies
---
+2 -1
View File
@@ -127,9 +127,10 @@ Completed components:
Deployment:
* Docker Compose project: sentry-self-hosted
* Management: slcompose orchestrator with Infisical secret injection
* Management: upstream Sentry self-hosted `install.sh` workflow
* External access: sentry.silveressence.net (Nginx Proxy Manager)
* Internal networking: Isolated sentry-self-hosted_default network
* Exception to the standard SilverLinux `slcompose` and Infisical service pattern
See [docs/sentry.md](sentry.md) for complete deployment documentation.
+9 -2
View File
@@ -151,6 +151,7 @@ Publicly exposed services:
* Jitsi Web
* BaGet
* Nextcloud
* Sentry
High-sensitivity exposure:
@@ -158,6 +159,7 @@ High-sensitivity exposure:
* Xray exposes tunneling capability and must be monitored for abuse, unexpected traffic and unauthorized use.
* Portainer exposes Docker management and must be restricted to trusted administrators.
* Nextcloud exposes private file storage and must require strong user authentication, HTTPS and prompt security updates.
* Sentry exposes application error data and must require strong authentication, HTTPS and careful project/token management.
Nginx Proxy Manager findings from the 2026-06-24 proxy-host snapshot:
@@ -168,13 +170,15 @@ Nginx Proxy Manager findings from the 2026-06-24 proxy-host snapshot:
* `cicd.silveressence.net` is intentionally enabled as a frequently changing prototype deployment endpoint.
* `exactsyncer.silveressence.net` is intentionally enabled as a client-facing Exact Online syncer demo endpoint.
* `cloud.silveressence.net` is enabled for Nextcloud with WebSocket and Block Exploits enabled, but SSL Force, HTTP/2 and HSTS disabled and no access list.
* `sentry.silveressence.net` is enabled for Sentry with SSL Force, HTTP/2, WebSocket and Block Exploits enabled; HSTS is disabled and no access list is assigned.
Priority hardening:
1. Enable SSL Force for all HTTPS public service routes unless there is a documented exception.
2. Enable SSL Force, HTTP/2 and HSTS for Nextcloud unless there is a documented exception.
3. Add an access list or equivalent restriction for DbGate and Portainer.
4. Define explicit exposure and authentication expectations for prototype and demo endpoints.
3. Enable HSTS for Sentry unless there is a documented exception.
4. Add an access list or equivalent restriction for DbGate and Portainer.
5. Define explicit exposure and authentication expectations for prototype and demo endpoints.
---
@@ -310,6 +314,7 @@ Network model:
* Isolated stack networks are used for Jitsi, Xray and CI/CD runner separation.
* `xray_default` currently exists without a running container attached; the active `xray` container is attached to `proxy`.
* `nextcloud_nextcloud_internal` isolates Nextcloud database and Redis traffic from the public proxy layer.
* `sentry-self-hosted_default` isolates Sentry databases, queues, workers and event processing services from shared application networks.
---
@@ -359,6 +364,8 @@ Periodically verify:
* Nextcloud security advisories are reviewed and the image is updated promptly
* Nextcloud database and Redis ports remain internal-only
* Nextcloud proxy route uses HTTPS with SSL Force, HTTP/2 and HSTS enabled unless there is a documented exception
* Sentry upstream self-hosted release notes are reviewed before updates
* Sentry internal services remain inaccessible except through the public Sentry web or nginx entry layer
* Public services are still routed only through Nginx Proxy Manager
* Removed proxy hosts and unused certificates stay removed unless explicitly approved
* Prototype and demo proxy hosts have documented owners and exposure expectations
+236 -119
View File
@@ -1,176 +1,293 @@
# Sentry (Self-Hosted)
# Sentry
## Overview
Sentry is the centralized error tracking and observability platform used across the SilverLinux infrastructure. It is deployed as a full self-hosted distributed system composed of multiple interconnected services.
Sentry is the centralized error tracking and observability platform for SilverLinux-hosted applications.
This deployment is production-ready and runs as an isolated Docker Compose stack.
Status:
```text
Operational
```
Public URL:
```text
https://sentry.silveressence.net
```
Deployment model:
```text
Upstream Sentry self-hosted install.sh
```
Sentry is intentionally documented as an exception to the standard SilverLinux `slcompose` and Infisical pattern. It is a much larger upstream self-hosted application and should be maintained according to the Sentry self-hosted project workflow.
---
## Service Status
## Runtime Stack
- Status: Running
- Compose Project: sentry-self-hosted
- Container Count: 70+ services
Compose project:
```text
sentry-self-hosted
```
Install directory:
```text
/srv/docker/sentry
```
Deployment method:
* Installed with Sentry self-hosted `install.sh`.
* Managed as one upstream Sentry self-hosted deployment unit.
* Not managed as a normal SilverLinux `slcompose` service.
* Not expected to use the standard per-service Infisical path pattern used by smaller SilverLinux services.
Runtime shape:
* 70+ containers
* Multiple internal queues, stores, workers and processing services
* One public web entry path through Nginx Proxy Manager
Key runtime containers from the 2026-07-08 snapshot:
| Container | Image | Role | Exposure |
| --- | --- | --- | --- |
| `sentry-self-hosted-nginx-1` | `nginx:1.31.0-alpine` | Public Sentry entry proxy | Publishes `0.0.0.0:9000 -> 80/tcp`; NPM forwards to `80` |
| `sentry-self-hosted-web-1` | `sentry-self-hosted-local` | Sentry web UI and API | Internal `9000/tcp` |
| `sentry-self-hosted-relay-1` | `ghcr.io/getsentry/relay:nightly` | Event ingestion relay | Internal `3000/tcp` |
| `sentry-self-hosted-postgres-1` | `postgres:14.23-bookworm` | Metadata database | Internal `5432/tcp` |
| `sentry-self-hosted-clickhouse-1` | `clickhouse-self-hosted-local` | Event storage | Internal `8123/tcp`, `9000/tcp`, `9009/tcp` |
| `sentry-self-hosted-redis-1` | `redis:6.2.20-alpine` | Cache and coordination | Internal `6379/tcp` |
| `sentry-self-hosted-kafka-1` | `confluentinc/cp-kafka:7.6.6` | Event stream buffer | Internal `9092/tcp` |
| `sentry-self-hosted-seaweedfs-1` | `chrislusf/seaweedfs:4.17_large_disk` | Object and attachment storage | Internal ports only |
---
## Public Access
Sentry is exposed via Nginx Proxy Manager:
Domain:
- Domain: https://sentry.silveressence.net
- Internal proxy container: sentry-self-hosted-nginx-1
- Port: 9000 → 80 (internal nginx proxy mapping)
```text
sentry.silveressence.net
```
Only the Nginx entry container is exposed externally. All other services are internal-only.
Public route:
```text
Internet
-> Nginx Proxy Manager
-> sentry-self-hosted-nginx-1
-> Sentry web/API services
```
Nginx Proxy Manager host:
| Setting | Value |
| --- | --- |
| Proxy host ID | `12` |
| Forward scheme | `http` |
| Forward host | `sentry-self-hosted-nginx-1` |
| Forward port | `80` |
| SSL Force | enabled |
| HTTP/2 | enabled |
| HSTS | disabled |
| HSTS subdomains | disabled |
| Block Exploits | enabled |
| WebSocket | enabled |
| Access List | none |
| Status | enabled |
Only the Sentry web or nginx entry layer should be public. Internal services such as PostgreSQL, ClickHouse, Redis, Kafka, Snuba and workers must stay internal to the Sentry deployment.
---
## Architecture Overview
## Architecture
Sentry is a distributed event processing pipeline:
Sentry is a distributed event processing pipeline.
```
Client Applications
→ Relay
→ Kafka
→ Snuba
→ ClickHouse
→ Web API (UI + Query Layer)
```text
Applications
-> Sentry SDK
-> Relay
-> Kafka
-> Snuba
-> ClickHouse
-> Web UI and API
```
---
Core components:
## Core Components
### Web Interface
- Container: sentry-self-hosted-web-1
- Purpose: UI + API layer
### Relay
- Container: sentry-self-hosted-relay-1
- Purpose: event ingestion gateway
### Kafka
- Container: sentry-self-hosted-kafka-1
- Purpose: event streaming backbone
### Snuba
- Multiple consumer containers
- Purpose: event processing and query engine
### ClickHouse
- Container: sentry-self-hosted-clickhouse-1
- Purpose: high-performance event storage
### PostgreSQL
- Container: sentry-self-hosted-postgres-1
- Purpose: metadata storage
### Redis
- Container: sentry-self-hosted-redis-1
- Purpose: caching and coordination
### Workers
Multiple background services:
- taskworker
- cron
- cleanup
- subscription consumers
- metrics processors
- ingestion pipelines
### Storage
- SeaweedFS used for object/file storage
* Web UI and API
* Relay
* Kafka
* Snuba
* ClickHouse
* PostgreSQL
* Redis
* SeaweedFS
* Task workers
* Cron and cleanup jobs
* Consumer and metrics processor services
---
## Networking
- Docker network: sentry-self-hosted_default
- External exposure: ONLY nginx container via proxy network
- All processing services remain isolated internally
Internal network:
---
```text
sentry-self-hosted_default
```
## Data Flow
Verified subnet:
1. Application sends events to Sentry SDK
2. Relay receives and validates events
3. Kafka buffers event streams
4. Snuba processes and transforms events
5. ClickHouse stores event data
6. Web service queries and displays results
```text
172.25.0.0/16
```
Public proxy attachment:
* Sentry is reachable at `https://sentry.silveressence.net` through Nginx Proxy Manager.
* The public route should terminate at the Sentry nginx or web entry container.
* Internal Sentry infrastructure containers must not be exposed directly.
Security boundary:
* Treat Sentry as its own upstream-managed application cluster.
* Do not attach Sentry databases or queues to shared application database networks unless there is a documented operational need.
* Keep Sentry credentials, generated secrets and upstream `.env` files out of this repository.
---
## Data Storage
- PostgreSQL → metadata
- ClickHouse → event storage
- Kafka → event streaming buffer
- Redis → caching/coordination
- SeaweedFS → attachments and file objects
Sentry stores data across multiple backing services:
| Component | Data role |
| --- | --- |
| PostgreSQL | Sentry metadata and relational state |
| ClickHouse | Event and analytics storage |
| Kafka | Event stream buffer |
| Redis | Cache and coordination |
| SeaweedFS | Attachments, files and object storage |
The upstream self-hosted installation directory and its Docker volumes are part of the recovery surface.
Verified configuration files:
```text
/srv/docker/sentry/.env
/srv/docker/sentry/docker-compose.yml
/srv/docker/sentry/sentry/sentry.conf.py
```
---
## Backup Requirements
The following must be backed up:
- PostgreSQL database volume
- ClickHouse data volume
- Sentry configuration files
- Any persistent Kafka data (if enabled)
Back up:
* `/srv/docker/sentry`
* Sentry `.env` and generated configuration files
* PostgreSQL volume
* ClickHouse volume
* Redis volume if persistence is enabled
* Kafka data if persistence is enabled
* SeaweedFS data
* Nginx Proxy Manager route and certificate state for `sentry.silveressence.net`
Secrets:
* Sentry generated secrets must stay out of Git.
* Do not move Sentry into the normal Infisical pattern unless the upstream deployment is intentionally redesigned.
* Preserve the upstream Sentry secret files through secure server backup and restore procedures.
Restore validation:
```text
Pending
```
Restore validation should include:
* Web UI login
* Project list visibility
* DSN availability
* Ingesting a test event
* Viewing the test event in the UI
* Confirming background consumers are healthy
---
## Management with slcompose
## Operations
Use the upstream Sentry self-hosted commands from the installation directory.
Typical command pattern:
### Start Sentry
```bash
slcompose up sentry
cd /srv/docker/sentry
sudo docker compose ps
sudo docker compose logs --tail=200
sudo docker compose up -d
```
### Stop Sentry
```bash
slcompose down sentry
```
### Restart Sentry
```bash
slcompose restart sentry
```
### View Live Logs
```bash
slcompose logs sentry
```
### View Recent Logs
```bash
slcompose logs-tail sentry 500
```
### View Injected Environment Variables
```bash
slcompose env sentry
```
Do not operate Sentry with `slcompose` unless the deployment is intentionally converted away from the upstream installer model.
---
## Important Notes
## Updates
- This is a distributed system; services must not be split or partially deployed.
- Updates must preserve service group integrity.
- Only the web/nginx layer should be exposed publicly.
- All 70+ containers are managed as a single atomic unit via slcompose.
Use the upstream Sentry self-hosted update workflow.
Before updating:
* Back up configuration and volumes.
* Review upstream release notes.
* Confirm available disk space.
* Verify the current deployment is healthy.
After updating:
* Confirm all containers are healthy.
* Verify `https://sentry.silveressence.net`.
* Send a test event from an application or SDK test client.
* Review worker, consumer, Kafka, Snuba and ClickHouse logs.
---
## Verification
Known verified facts:
* Sentry was installed using the upstream self-hosted `install.sh`.
* Sentry is available at `https://sentry.silveressence.net`.
* Sentry install directory is `/srv/docker/sentry`.
* Sentry nginx entry container is `sentry-self-hosted-nginx-1`.
* Nginx Proxy Manager forwards `sentry.silveressence.net` to `http://sentry-self-hosted-nginx-1:80`.
* `sentry-self-hosted-nginx-1` publishes `0.0.0.0:9000 -> 80/tcp`.
* `sentry-self-hosted_default` subnet is `172.25.0.0/16`.
* Sentry is treated as the exception to the standard SilverLinux `slcompose` and Infisical service pattern.
Recommended next runtime capture:
```bash
docker ps --filter "name=sentry" --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"
docker network inspect proxy sentry-self-hosted_default --format 'network={{.Name}} containers={{range $id,$c := .Containers}}{{$c.Name}} {{end}}'
```
---
## Related Documentation
- [orchestration.md](orchestration.md) — Service orchestration with slcompose
- [AI_CONTEXT.md](AI_CONTEXT.md) — Infrastructure overview
- [services.md](services.md) — All services on SilverLinux
* [docs/services.md](services.md)
* [docs/domains.md](domains.md)
* [docs/network.md](network.md)
* [docs/security.md](security.md)
* [docs/backups.md](backups.md)
* [docs/secrets.md](secrets.md)
+42
View File
@@ -168,6 +168,7 @@ Examples:
* Grafana
* Node Exporter
* cAdvisor
* Sentry
* Nextcloud
---
@@ -196,6 +197,7 @@ Contains:
/srv/docker/xray
/srv/docker/monitoring
/srv/docker/nextcloud
/srv/docker/sentry
```
---
@@ -373,6 +375,45 @@ The 2026-07-08 runtime snapshot showed `nextcloud`, `nextcloud-db` and `nextclou
---
### Sentry
Deployment:
```text
Upstream Sentry self-hosted install.sh
```
Install directory:
```text
/srv/docker/sentry
```
Domain:
```text
sentry.silveressence.net
```
Network:
```text
sentry-self-hosted_default
```
Public entry:
```text
sentry-self-hosted-nginx-1
0.0.0.0:9000 -> 80/tcp
```
Runtime note:
Sentry is available through Nginx Proxy Manager at `https://sentry.silveressence.net`. It is maintained as an upstream self-hosted Sentry deployment and is the exception to the standard SilverLinux `slcompose` and Infisical service model.
---
### Monitoring Stack
```text
@@ -422,6 +463,7 @@ Implemented:
* PostgreSQL not exposed publicly
* MSSQL port 1433 not exposed publicly
* Nextcloud PostgreSQL and Redis not exposed publicly
* Sentry backing services not exposed publicly
* Database administration is available only through authenticated HTTPS access to DbGate
* Xray is not attached to the private database network and is monitored as a tunneling endpoint
* OpenID disabled in Gitea
+13 -3
View File
@@ -529,6 +529,12 @@ Architecture:
* Components: Relay, Kafka, Snuba, ClickHouse, PostgreSQL, Redis, SeaweedFS
* Self-hosted deployment
Entry container:
* `sentry-self-hosted-nginx-1` using `nginx:1.31.0-alpine`
* Publishes `0.0.0.0:9000 -> 80/tcp`
* Nginx Proxy Manager forwards to `sentry-self-hosted-nginx-1:80`
Networks:
* `proxy` for Nginx Proxy Manager access
@@ -536,9 +542,11 @@ Networks:
Management:
* Managed via slcompose orchestrator
* Automated Infisical secret injection
* Single atomic deployment unit
* Installed with upstream Sentry self-hosted `install.sh`
* Install directory: `/srv/docker/sentry`
* Managed according to the upstream Sentry self-hosted workflow
* Exception to the standard SilverLinux `slcompose` and Infisical pattern
* Single atomic upstream deployment unit
Data Storage:
@@ -549,9 +557,11 @@ Data Storage:
Backup Requirements:
* `/srv/docker/sentry`
* PostgreSQL database volume
* ClickHouse data volume
* Sentry configuration files
* SeaweedFS data
* Persistent Kafka data (if enabled)
Status: