Production Checklist

Comprehensive checklist for deploying Gate proxy to production

Before deploying Gate to production, ensure you’ve completed all items in this checklist to maintain security, reliability, and optimal performance.

Security Configuration

Authentication & Player Security

1. Enable online mode

   Always use online mode in production to authenticate players with Mojang.

   config.yml

   config:
     onlineMode: true
   

   Setting onlineMode: false allows unauthenticated players and is a major security risk.

2. Configure forwarding mode

   Set up secure player information forwarding to backend servers.

   config.yml

   config:
     forwarding:
       mode: velocity  # Recommended: velocity or bungeeguard
       velocitySecret: ${GATE_VELOCITY_SECRET}
   

   Available modes:

   • velocity - Modern, secure (recommended)
   • bungeeguard - Token-based security
   • legacy - BungeeCord compatibility (less secure)
   • none - No forwarding (not recommended)

   Store secrets in environment variables, never commit them to version control.

3. Generate strong secrets

   Create cryptographically secure secrets for forwarding.

   # Generate a secure random secret
   openssl rand -base64 32
   
   # Or use uuidgen
   uuidgen
   

   Set as environment variable:

   export GATE_VELOCITY_SECRET="your-generated-secret-here"
   
4. Enable force key authentication

   Enforce Minecraft 1.19+ security standards.

   config.yml

   config:
     forceKeyAuthentication: true
   
5. Require permissions for commands

   Prevent unauthorized access to proxy commands.

   config.yml

   config:
     requireBuiltinCommandPermissions: true
   
6. Disable untrusted plugin channels

   Protect against malicious backend servers.

   config.yml

   config:
     bungeePluginChannelEnabled: false  # Set to false if backends are untrusted
   

Network Security

1. Enable rate limiting

   Protect against DDoS and brute force attacks.

   config.yml

   config:
     quota:
       connections:
         enabled: true
         ops: 5      # Operations per second
         burst: 10   # Burst capacity
         maxEntries: 1000
       logins:
         enabled: true
         ops: 0.4
         burst: 3
         maxEntries: 1000
   
2. Configure proxy protocol (if behind load balancer)

   Preserve real client IP addresses.

   config.yml

   config:
     proxyProtocol: true
   

   Only enable if you’re behind a trusted load balancer. Enabling this without a load balancer allows IP spoofing.

3. Secure API endpoint

   If using the HTTP API, bind to localhost or use proper authentication.

   config.yml

   api:
     enabled: true
     bind: localhost:8080  # Use localhost in production
   

   For external access, use a reverse proxy with authentication:

   nginx.conf

   location /api/ {
     proxy_pass http://localhost:8080/;
     auth_basic "Gate API";
     auth_basic_user_file /etc/nginx/.htpasswd;
   }
   
4. Configure backend server addresses

   Use internal network addresses for backend servers.

   config.yml

   config:
     servers:
       lobby: 10.0.1.10:25565      # Internal IP
       survival: 10.0.1.11:25565   # Internal IP
       creative: 10.0.1.12:25565   # Internal IP
   

   Backend servers should never be directly exposed to the internet.

5. Disable backend server online mode

   Backend servers should trust Gate’s forwarding.

   server.properties

   online-mode=false
   

   Configure backend to accept forwarded player data based on your forwarding mode.

Performance Optimization

1. Optimize compression settings

   Balance between bandwidth and CPU usage.

   config.yml

   config:
     compression:
       threshold: 256  # Vanilla default
       level: -1       # Default compression
   

   Recommendations:

   • High bandwidth, limited CPU: level: 0 (no compression)
   • Limited bandwidth: level: 6 (higher compression)
   • Balanced: level: -1 (default)
2. Configure timeouts

   Adjust for your network conditions.

   config.yml

   config:
     connectionTimeout: 5s
     readTimeout: 30s  # Increase to 60s if using Forge
   
3. Enable automatic reconnection

   Improve player experience during server issues.

   config.yml

   config:
     failoverOnUnexpectedServerDisconnect: true
   
4. Optimize server try list

   Order servers by priority and capacity.

   config.yml

   config:
     try:
       - lobby-1    # Primary lobby
       - lobby-2    # Fallback lobby
       - lobby-3    # Secondary fallback
   

Monitoring & Observability

1. Enable health checks

   Configure gRPC health service for Kubernetes/load balancers.

   config.yml

   healthService:
     enabled: true
     bind: 0.0.0.0:9090
   
2. Enable OpenTelemetry

   Export metrics and traces to your observability platform.

   docker-compose.yml

   environment:
     - OTEL_SERVICE_NAME=gate-production
     - OTEL_METRICS_ENABLED=true
     - OTEL_TRACES_ENABLED=true
     - OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317
   
3. Configure logging

   Disable debug mode in production.

   config.yml

   config:
     debug: false
     status:
       logPingRequests: false  # Reduce log noise
   
4. Set up alerting

   Monitor critical metrics:

   • Player connection failures
   • Backend server availability
   • High latency or packet loss
   • Resource usage (CPU, memory)
   • Error rates

High Availability

1. Deploy multiple instances

   Run at least 2 Gate instances for redundancy.

   kubernetes

   spec:
     replicas: 3  # Minimum 2 for HA
   
2. Configure load balancer health checks

   Use the gRPC health service endpoint.

   livenessProbe:
     grpc:
       port: 9090
     initialDelaySeconds: 10
     periodSeconds: 10
     failureThreshold: 3
   
   readinessProbe:
     grpc:
       port: 9090
     initialDelaySeconds: 5
     periodSeconds: 5
     failureThreshold: 2
   
3. Set up resource limits

   Prevent resource exhaustion.

   kubernetes

   resources:
     requests:
       memory: "1Gi"
       cpu: "1000m"
     limits:
       memory: "2Gi"
       cpu: "2000m"
   
4. Configure pod disruption budgets

   Ensure minimum availability during updates.

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: gate-pdb
   spec:
     minAvailable: 2
     selector:
       matchLabels:
         app: gate
   
5. Enable graceful shutdown

   Configure custom shutdown message.

   config.yml

   config:
     shutdownReason: |
       §eServer maintenance in progress.
       §7Please reconnect in a few moments.
   

Configuration Validation

1. Test configuration locally

   Validate before deploying.

   # Run Gate with your config
   ./gate -config config.yml
   
   # Check for warnings or errors in logs
   
2. Verify server connectivity

   Ensure all backend servers are reachable.

   # Test from Gate's network
   nc -zv 10.0.1.10 25565
   nc -zv 10.0.1.11 25565
   
3. Test player authentication

   Verify online mode and forwarding work correctly.

   1. Connect with a real Minecraft account
   2. Verify UUID is correct on backend
   3. Check player skin loads properly
   4. Test server switching
4. Load testing

   Test with realistic player counts.

   # Use minecraft-bot or similar tools
   # Start with small numbers and increase gradually
   

Backup & Disaster Recovery

1. Backup configuration

   Version control your config files.

   git init
   git add config.yml
   git commit -m "Production configuration"
   git push origin main
   
2. Document secrets

   Store secrets securely (e.g., HashiCorp Vault, AWS Secrets Manager).

   # Never commit secrets to git
   echo "GATE_VELOCITY_SECRET=*" >> .gitignore
   
3. Create rollback plan

   Document steps to revert to previous version.

   1. Keep previous Docker image tags
   2. Maintain config backups
   3. Test rollback procedure
4. Monitor deployment

   Watch for issues after deployment.

   # Kubernetes
   kubectl logs -f deployment/gate
   
   # Docker
   docker logs -f gate
   

Pre-Launch Checklist

Before going live, verify:

• Online mode is enabled
• Forwarding mode is configured with strong secret
• Rate limiting is enabled
• Backend servers are configured correctly
• Health checks are working
• Monitoring and alerting are set up
• Multiple instances are running (HA)
• Load balancer is configured
• Resource limits are set
• Debug mode is disabled
• Configuration is backed up
• Rollback procedure is documented
• Team is trained on operations
• Incident response plan is ready

Post-Deployment

1. Monitor for 24-48 hours

   Watch metrics closely after launch:

   • Player connection success rate
   • Latency and performance
   • Error logs
   • Resource usage
2. Gather feedback

   Monitor community channels for issues:

   • Connection problems
   • Performance complaints
   • Feature requests
3. Document operations

   Create runbooks for:

   • Common issues and fixes
   • Scaling procedures
   • Update process
   • Emergency procedures
4. Plan regular maintenance

   Schedule:

   • Weekly: Review metrics and logs
   • Monthly: Update to latest Gate version
   • Quarterly: Security audit
   • Annually: Architecture review

Common Production Issues

Issue: Players can’t connect

Checklist:

• Verify Gate is running: docker ps or kubectl get pods
• Check port is open: nc -zv <gate-ip> 25565
• Review logs for errors
• Verify firewall rules
• Check rate limiting hasn’t blocked legitimate players

Issue: Backend server connection failed

Checklist:

• Verify backend server is running
• Check server address in config
• Test network connectivity from Gate to backend
• Verify forwarding is configured on backend
• Check backend server logs

Issue: Players have wrong UUIDs

Checklist:

• Verify online mode is enabled on Gate
• Check forwarding mode matches backend configuration
• Ensure forwarding secret matches on all servers
• Verify backend server is in offline mode

Issue: High memory usage

Solutions:

• Review compression settings
• Check for connection leaks
• Increase resource limits if needed
• Monitor for DDoS attacks
• Review quota settings

Security Incident Response

If you suspect a security breach:

1. Immediate actions:

   • Review access logs
   • Check for unauthorized configuration changes
   • Verify forwarding secrets haven’t been compromised

2. Containment:

   • Rotate forwarding secrets if compromised
   • Update configuration on all servers
   • Review and tighten security settings

3. Recovery:

   • Restore from known-good configuration
   • Verify system integrity
   • Monitor for continued suspicious activity

4. Post-incident:

   • Document what happened
   • Update security procedures
   • Train team on new procedures

Next Steps

Monitoring Setup

Configure metrics, logging, and health checks

Configuration Reference

Detailed configuration options