silverlinux-infra/docs/network.md

Network Architecture

Overview

SilverLinux uses Docker networks to separate public entry points, private service communication and isolated infrastructure stacks.

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

Verified runtime snapshot:

2026-06-24 10:15 CEST

---

Network Layers

Internal Layer

Purpose:

• Private database access
• Backend-to-database communication
• Service traffic that should not be reachable from the internet

Network:

internal

Services:

• PostgreSQL
• Microsoft SQL Server Express
• Gitea backend connectivity
• OpenProject backend connectivity
• DbGate database connectivity

Policy:

• Database ports must not be published on the host
• Database engines must not be routed through Nginx Proxy Manager
• Only containers that require private backend access should join this network

---

Proxy Layer

Purpose:

• Public HTTP and HTTPS entry point
• SSL termination
• Domain routing through Nginx Proxy Manager

Network:

proxy

Public services:

• Gitea
• OpenProject
• Portainer
• DbGate
• Xray
• Jitsi Web
• BaGet

Internal monitoring services:

• Prometheus
• Grafana
• Node Exporter
• cAdvisor
• Alertmanager

Verified subnet:

172.18.0.0/16

Policy:

• Nginx Proxy Manager is the single reverse proxy system
• HTTP services should be exposed through Nginx Proxy Manager instead of direct host ports
• Public management and administration services require strong authentication

---

Isolated Infrastructure Layers

Purpose:

• Keep specialized stacks separate from the shared application and database networks
• Limit cross-service traffic to only the attachments each stack requires

Networks:

jitsi-docker-jitsi-meet-aa76415_meet.jitsi
xray_default
gitea-runner_default
monitoring stack network

jitsi-docker-jitsi-meet-aa76415_meet.jitsi

Purpose:

• Isolated Jitsi communication cluster

Services:

• jitsi-web
• jitsi-jvb
• jitsi-jicofo
• jitsi-prosody

Public attachment:

• All currently running Jitsi containers also attach to proxy.
• Public user access is expected through the Jitsi Web component.

Verified subnet:

172.20.0.0/16

xray_default

Purpose:

• Isolated tunneling and connectivity system
• Compose-created network for the Xray stack

Services:

• No running containers were attached in the 2026-06-24 runtime snapshot

Public attachment:

• The running xray container is attached to proxy.
• The running xray container was not attached to xray_default in the 2026-06-24 runtime snapshot.

Verified subnet:

172.22.0.0/16

Gluetun PIA VPN Gateway

Purpose:

• Containerized VPN gateway for Private Internet Access (PIA)
• Isolate VPN traffic from host networking and production services

Services:

• gluetun-pia
• xray-pia (via container:gluetun-pia network mode)

Notes:

• gluetun-pia routes selected container traffic through PIA WireGuard
• xray-pia is a secondary VLESS endpoint that uses the Gluetun VPN gateway
• Production xray remains isolated on the direct OVH path

Verified isolation:

• VPN traffic is contained inside the gluetun-pia container namespace
• Host routing remains unchanged by VPN activity

gitea-runner_default

Purpose:

• Runner execution and workflow isolation
• Keep build traffic separate from public services and private databases unless explicit access is required

Runtime attachment:

• gitea-runner is attached to both gitea-runner_default and internal.

Verified subnet:

172.21.0.0/16

Monitoring Stack Network

Purpose:

• Dedicated monitoring stack communication
• Prometheus scraping of monitoring targets
• Grafana datasource connectivity to Prometheus

Services:

• Prometheus
• Grafana
• Node Exporter
• cAdvisor
• Alertmanager

Validated:

• Prometheus scrapes Prometheus
• Prometheus scrapes Node Exporter
• Prometheus scrapes cAdvisor
• Prometheus scrapes SilverLinux backup metrics
• Grafana connects to Prometheus
• Alertmanager routes monitoring alerts

---

Runtime-Published Ports

The current Docker runtime includes these host-published ports.

Service	Published port	Container port	UFW state	Notes
Nginx Proxy Manager	80, 81, 443	80, 81, 443	80 and 443 allowed; 81 not listed	Public proxy and NPM admin interface
Gitea	2222	22	Allowed	Git SSH access
OpenProject	8082	80	Not listed as allowed	Direct HTTP port also published
BaGet	5555	80	Not listed as allowed	Direct HTTP port also published
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

Additional UFW allowed ports with no matching Docker-published service in the 2026-06-24 Docker snapshot:

• 8080/tcp
• 8085/tcp
• 8444/tcp

Database ports:

• PostgreSQL exposes 5432/tcp only inside Docker.
• MSSQL exposes 1433/tcp only inside Docker.
• DbGate exposes 3000/tcp only inside Docker.

---

Topology Summary

Internet
  -> Nginx Proxy Manager
     -> proxy network
        -> Gitea
        -> OpenProject
        -> Portainer
        -> DbGate
        -> Xray
        -> Jitsi Web
        -> BaGet

internal network
  -> PostgreSQL
  -> Microsoft SQL Server Express
  -> backend service database access

isolated networks
  -> jitsi-docker-jitsi-meet-aa76415_meet.jitsi
  -> xray_default
  -> gitea-runner_default
  -> monitoring stack network

---

Default Docker Networks

Docker default networks remain present:

• bridge
• host
• none

These are system defaults and are not the preferred routing model for SilverLinux application services.

---

Verification Checklist

Periodically verify:

• PostgreSQL and MSSQL are attached only to private networks required by their consumers
• Nginx Proxy Manager remains the only reverse proxy for HTTP services
• Nginx Proxy Manager routes match the documented proxy-host table in docs/domains.md
• DbGate authentication is enabled and tested
• DbGate and Portainer have an access restriction policy
• Xray exposure policy is documented and monitored
• Jitsi Web is reachable through proxy
• 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
• UFW-only allowed ports have documented owners
• Prometheus targets remain healthy
• Grafana datasource connection remains healthy
• Unused Docker networks are removed only after confirming they are not active dependencies

---

Related Documentation

• docs/services.md
• docs/security.md
• docs/monitoring.md
• docs/decisions.md
• nginx-proxy-manager/README.md