Network Security Guide
This guide describes recommended network controls for deploying Enprivacy 3.0 in a secure, network-isolated environment.
Design Principles
Section titled “Design Principles”Enprivacy 3.0 is designed to operate in a network-restricted environment. At runtime, the only required outbound internet connection is to auth.enprivacy.com for user authentication and entitlement.
On first use, the Web, Job, and LLM services download models from the Hugging Face Hub. These downloads can be avoided entirely by pre-loading models into durable storage as a one-off action, allowing fully air-gapped operation — see Air-Gapped Deployments.
Required Outbound Connections
Section titled “Required Outbound Connections”| Destination | Port | Purpose | Required |
|---|---|---|---|
auth.enprivacy.com | 443 (HTTPS) | User authentication and entitlement | Always |
huggingface.co, cdn-lfs.huggingface.co, cdn-lfs-us-1.hf.co, cdn-lfs-eu-1.hf.co, cdn-lfs.hf.co, cas-bridge.xethub.hf.co | 443 (HTTPS) | Model downloads (Web, Job, LLM services) on first use | Only if models are not pre-loaded |
Once models are pre-loaded, all outbound connectivity except auth.enprivacy.com:443 can be blocked at the network layer.
If you use an external/hosted LLM provider (e.g. AWS Bedrock, Azure OpenAI, Google Vertex) instead of the bundled LLM service, allow-list that provider’s endpoints in place of the Hugging Face Hub URLs.
Interservice Communications
Section titled “Interservice Communications”Services communicate over the following default ports. Only the Web service needs to be exposed for administrative and end-user access; all other services should be reachable only from within the deployment’s private network.
| From | To | Port | Protocol |
|---|---|---|---|
| Internet | Web | 8080 | HTTP |
| Web | Database | 5432 | TCP |
| Job | Database | 5432 | TCP |
| Web | LLM | 8000 | HTTP |
| Job | LLM | 8000 | HTTP |
| Web | OCR | 5001 | HTTP |
| Job | OCR | 5001 | HTTP |
Interservice traffic uses plain HTTP/TCP by default and is intended to run within a trusted private network or segment. Where in-transit encryption between services is required, apply it at the network layer or via a service mesh (e.g. mTLS / WireGuard) — the application does not enforce TLS on these internal ports.
Recommended Firewall Rules
Section titled “Recommended Firewall Rules”Inbound
Section titled “Inbound”Outbound
Section titled “Outbound”Network Segmentation
Section titled “Network Segmentation”TLS Configuration
Section titled “TLS Configuration”- Only the Web service is exposed publicly. Terminate HTTPS at your load balancer or ingress controller using a certificate for your selected domain(s).
- Bring your own certificate from a trusted CA, or configure Enprivacy 3.0 to provision certificates via Let’s Encrypt. Enprivacy can help you select and implement an appropriate approach.
- Internal service-to-service traffic uses the ports listed under Interservice Communications and is not TLS-encrypted by default; isolate it within a private network or apply network-layer encryption.
VPN / Zero Trust Access
Section titled “VPN / Zero Trust Access”Air-Gapped Deployments
Section titled “Air-Gapped Deployments”Enprivacy 3.0 can run without general outbound internet access:
- Pre-load the required models into each service’s durable model cache (
~/.cache) as a one-off action, so the Web, Job, and LLM services do not need to reach the Hugging Face Hub. - Use a self-hosted PostgreSQL database (with the required extensions) and an S3-compatible object store within your network.
- Allow only
auth.enprivacy.com:443outbound, for user authentication and entitlement.