Every network connection in Phala Cloud is end-to-end encrypted. Here’s how the network security works and what it means for your application architecture.

​
Traffic Encryption Layers

Your network traffic goes through multiple encryption layers, each protecting against different threats.

​
The Encryption Stack

When a client calls https://deadbeef111111111111111111111111-8080.dstack-prod5.phala.network/api, the request travels through: 
Client → [TLS 1.3] → Gateway → [WireGuard] → CVM → [Plain HTTP] → Your Container
The gateway terminates TLS and re-encrypts with WireGuard before forwarding to your CVM. The gateway is deployed in Phala Cloud TEE to ensure the traffic is always end-to-end encrypted. Inside the CVM, traffic between your containers is encrypted in the CVM memory and protected by TEE.

​
TLS Passthrough Mode

Sometimes you need unmodified TLS all the way to your application. Add the s suffix to your URL: 
Client → [TLS] → Gateway → [WireGuard + TLS] → CVM → [TLS] → Your Container
The gateway sees encrypted bytes and forwards them without decryption. Your container handles the TLS termination. Use this for:
  • PostgreSQL/MySQL with sslmode=require and self managed certificates
  • Services that verify client certificates
  • Custom protocols that manage their own TLS
Example connection string: 
psql "host=deadbeef111111111111111111111111-5432s.dstack-prod5.phala.network port=443 sslmode=require"

​
Network Isolation

Each CVM gets its own isolated network segment. Here’s what that means practically.

​
CVM Network Boundaries

Your CVM has:
  • A unique WireGuard tunnel with its own keypair
  • An isolated IP in the 10.0.0.0/8 range
  • No route to other CVMs or the host
You can’t ping another CVM. You can’t connect to the host’s localhost. You can’t even discover what other CVMs exist on the same server.

​
Container Networking Inside CVM

Within your CVM, containers communicate normally via Docker’s bridge network: 
services:
  frontend:
    # Can reach backend at http://backend:3000
  backend:
    # Can reach postgres at postgres://db:5432
  db:
    # All internal, no encryption needed
This internal traffic never leaves the CVM’s memory space, which is already hardware-encrypted.

​
Outbound Connections (Egress)

CVMs have full outbound internet connectivity with privacy protections through TEE isolation. Supported Protocols: Your containers can use any standard internet protocol:
  • TCP/UDP for basic connectivity
  • HTTP/HTTPS for web services and APIs
  • WebSocket for real-time communication
  • gRPC for modern microservices
  • Database protocols (PostgreSQL, MySQL, Redis)
  • Email protocols (SMTP, POP3, IMAP)
  • File transfer protocols (FTP, SFTP)
  • ICMP for ping utility
Isolation from Host: While your CVM has full internet access, it’s isolated from the host:
  • Cannot access host’s 127.0.0.1 services
  • Limited access to host’s local network
  • Cannot discover or attack host infrastructure
Privacy Protection: The combination of WireGuard tunneling and TEE isolation means:
  • Host sees a connection was made but not the content
  • Memory contents remain encrypted and isolated
  • No data leakage to host or other CVMs
  • Application behavior stays private even with network monitoring

​
How SNI Routing Works

The gateway uses Server Name Indication (SNI) to route traffic without decrypting it.

​
Standard Mode Routing

For deadbeef111111111111111111111111-8080.dstack-prod5.phala.network:
  1. Client sends TLS ClientHello with SNI
  2. Gateway extracts deadbeef111111111111111111111111-8080 from SNI
  3. Looks up which CVM has app-id deadbeef111111111111111111111111
  4. Forwards to that CVM’s WireGuard tunnel on port 8080
The gateway can see which app and port you’re accessing but not the request content.

​
Passthrough Mode Routing

For deadbeef111111111111111111111111-5432s.dstack-prod5.phala.network:
  1. Gateway sees the s suffix in SNI
  2. Establishes TCP tunnel without TLS termination
  3. Your container receives the raw TLS stream
The gateway can’t see anything except encrypted bytes.

​
Load Balancing and Health Checks

Understanding how the gateway distributes traffic helps you design resilient services.

​
Health-Based Routing

The gateway tracks WireGuard handshake times:
  • Last handshake < 5 minutes ago = healthy
  • No recent handshake = unhealthy
Unhealthy instances stop receiving traffic automatically. No need for explicit health endpoints, though you can add them for container-level health.

​
Session Affinity

Currently there’s no sticky sessions. Requests distribute across healthy instances randomly. Design implications: 
// DON'T: Store session in memory
req.session.userId = 'user123';

// DO: Use external storage
await redis.set(`session:${sessionId}`, userData);
For WebSocket connections, the TCP connection stays with one instance for its lifetime. But reconnections might hit a different instance.

​
Security Boundaries

Understanding what’s protected and what isn’t helps you make architectural decisions.

​
What the Network Security Provides

Cloud insider attack resilience: All the traffic is end-to-end encrypted by default. Even the cloud provider can’t access your data. CVM isolation: Network segmentation prevents lateral movement between CVMs. Traffic analysis resistance: WireGuard hides packet sizes and timing patterns.

​
What You Still Need to Handle

Application-layer auth: Network security doesn’t replace authentication. 
// Still needed
if (!req.headers.authorization) {
  return res.status(401).send('Unauthorized');
}
Rate limiting: Network layer doesn’t prevent abuse. 
// Still recommended
app.use(rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100
}));
Input validation: Network encryption doesn’t prevent injection attacks. 
// Still critical
const sanitized = validator.escape(userInput);

​
Common Patterns and Solutions

​
Database Connections

For managed databases requiring TLS: 
// Use passthrough mode
const db = new Pool({
  host: 'deadbeef111111111111111111111111-5432s.dstack-prod5.phala.network',
  port: 443,
  ssl: {
    rejectUnauthorized: true,
    ca: fs.readFileSync('server-ca.pem')
  }
});

​
Microservice Communication

For service-to-service within the same CVM: 
// Use internal DNS names, no TLS needed
const userService = 'http://users:3000';
const authService = 'http://auth:4000';
For cross-CVM communication: 
// Use public URLs with TLS
const otherService = 'https://abc456-9000.dstack-prod5.phala.network';

​
WebSocket Connections

WebSockets work over the standard HTTPS endpoint: 
// Client side
const ws = new WebSocket('wss://deadbeef111111111111111111111111-8080.dstack-prod5.phala.network/ws');

// Server side - no special config needed
wss.on('connection', (ws) => {
  // Connection already secured by gateway TLS
});

​
Debugging Network Issues

​
Checking Connectivity

From inside your container: 
# Test outbound
curl -I https://example.com

# Check internal DNS
nslookup other-service

# View network interfaces
ip addr show

# Check routing table
ip route

​
TLS Debugging

For passthrough mode issues: 
# Test TLS handshake
openssl s_client -connect deadbeef111111111111111111111111-5432s.dstack-prod5.phala.network:443

# Check certificate
openssl s_client -connect deadbeef111111111111111111111111-5432s.dstack-prod5.phala.network:443 | openssl x509 -text

​
Traffic Analysis

You can’t capture WireGuard traffic (it’s encrypted), but you can see container traffic: 
# Inside container (install tcpdump first)
tcpdump -i eth0 -n port 80

# Connection count
netstat -an | grep ESTABLISHED | wc -l
Remember: the host can’t run these commands inside your CVM. Only you can debug your own traffic.

​
Advanced Privacy Patterns

​
Anonymous Hosting with Tor

For maximum privacy, you can combine TEE security with Tor hidden services. This provides both confidential computing and network anonymity:
  • Deploy a Tor hidden service inside your CVM
  • Use internal Docker networking between Tor and your application
  • Request TEE attestation based on the .onion address
  • Clients can verify both the Tor anonymity and TEE authenticity
This pattern is useful for whistleblowing platforms, private communications, or any service requiring both computational and network privacy. Check the dstack-examples repository for a complete Tor hidden service implementation.