Load Balancer Config Generator
Generate highly available TCP/HTTP load balancer configurations for NGINX, HAProxy, and Kubernetes Services.
What is this tool?
The Load Balancer Configuration Generator helps you scale your applications horizontally across multiple backend servers using NGINX or HAProxy.
When a single server can no longer handle the traffic volume, a load balancer acts as a traffic cop, sitting in front of your servers and routing client requests across all servers capable of fulfilling them in a manner that maximizes speed and capacity utilization. This tool ensures no single server gets overworked, automatically handling degraded servers with built-in health checks.
How to Use This Tool
1. Define Upstreams: Enter the IP addresses or hostnames of your backend application servers. These form the 'upstream pool'.
2. Choose an Algorithm: Select how traffic is distributed. Round Robin cycles through servers sequentially. Least Connections sends traffic to the server with the fewest active requests. IP Hash ensures a specific user always hits the same backend server (useful for session state).
3. Configure Health Checks: Enable active (HAProxy) or passive (NGINX) health checks. If a backend server fails to respond, the load balancer temporarily removes it from the pool until it recovers.
4. Session Persistence: If your application stores user sessions in memory (instead of a shared database like Redis), you can enable sticky sessions to bind a user's session to a specific server via cookies.
Best Practices
- Always use **Least Connections** (`least_conn`) instead of Round Robin if your application has long-lived requests or unpredictable response times. This prevents slow requests from piling up on a single server.
- If your application uses WebSockets, ensure you increase the `proxy_read_timeout`. Load balancers typically drop idle HTTP connections after 60 seconds, which will prematurely disconnect WebSocket users.
- Configure `max_fails` and `fail_timeout` on your upstream servers to instruct the load balancer exactly when to consider a node 'dead' and how long to wait before retrying it.
- Offload SSL/TLS termination at the load balancer layer. This significantly reduces the CPU load on your backend application servers.
Common Mistakes
- Using IP Hashing behind Cloudflare or another CDN. Because all traffic comes from the CDN's IP addresses, IP Hashing will route *all* traffic to a single backend server, entirely defeating the load balancer.
- Forgetting to share session state (e.g., PHP sessions) between backend servers without enabling Sticky Sessions. Users will randomly get logged out as they are routed to different nodes.
- Not setting `proxy_set_header X-Forwarded-For`. Without this, every backend server will think every request is coming from the internal IP of the Load Balancer.
Security Notes
- Place your backend application servers on a private network (VPC/LAN) that is completely isolated from the internet. Only the Load Balancer should have a public IP address.
- Configure a WAF (Web Application Firewall) at the load balancer layer to filter malicious traffic before it ever reaches your application servers.
- Set strict Connection Limits (`conn_limit`) per IP address at the load balancer to mitigate volumetric DDoS attacks.
Production Tips
- Enable Keep-Alive between the Load Balancer and the backend servers. This prevents the load balancer from having to negotiate a new TCP handshake for every single request forwarded to the backend.
- If using HAProxy, use the `httpchk` option to make HAProxy explicitly request a `/health` endpoint on your app. TCP checks only verify the port is open; HTTP checks verify the app is actually alive.
- Set a backup server (`backup` flag) in your upstream pool that only receives traffic if all primary servers fail. This is perfect for showing a static 'Maintenance Mode' page.
Frequently Asked Questions
Which algorithm should I use?
What is an Active vs Passive Health Check?
Can a Load Balancer improve database performance?
How We Keep Your Configs Safe & Valid
Built-in Error Checking
Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.
100% Private & Local
All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.
Secure Settings by Default
Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.
Ready for CI/CD & Git
Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.
Infrastructure as Code
Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.
Monitoring & Tracing
Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.
Container & Docker Safety
Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.
Multiple Output Formats
Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.