fabio

Consul Load-Balancing made simple

7,254

619

7,254

252

View on GitHub

Top Related Projects

traefik

50,061

The Cloud Native Application Proxy

nginx

22,139

The official NGINX Open Source repository.

envoy

24,693

Cloud-native high-performance edge/middle/service proxy

haproxy

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

mesh

2,022

Traefik Mesh - Simpler Service Mesh

linkerd2

10,567

Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.

Quick Overview

Fabio is a fast, modern, zero-conf load balancing HTTP(S) and TCP router for deploying microservices managed by Consul. It automatically discovers services and configures itself in real-time, making it ideal for dynamic environments and microservice architectures.

Pros

Zero-configuration: Automatically discovers services and configures routing
High performance: Written in Go, optimized for speed and efficiency
Flexible: Supports HTTP, HTTPS, and TCP routing
Consul integration: Seamlessly works with Consul for service discovery

Cons

Limited to Consul: Primarily designed for use with Consul, which may not suit all environments
Learning curve: May require understanding of Consul and service discovery concepts
Limited advanced features: Some advanced load balancing features might be missing compared to more established solutions

Getting Started

Install Fabio:

go get github.com/fabiolb/fabio

Start Consul:

consul agent -dev

Configure your services to register with Consul
Start Fabio:

fabio

Access your services through Fabio's default port (9999):

http://localhost:9999/service-name

Fabio will automatically discover and route traffic to your registered services.

Competitor Comparisons

traefik

50,061

The Cloud Native Application Proxy

Pros of Traefik

More extensive feature set, including automatic HTTPS, TCP support, and middleware
Better documentation and community support
Easier configuration with multiple providers (Docker, Kubernetes, file-based, etc.)

Cons of Traefik

Higher resource usage, especially in large-scale deployments
Steeper learning curve due to more complex configuration options
Less focus on performance optimization compared to Fabio

Code Comparison

Traefik configuration (YAML):

http:
  routers:
    my-router:
      rule: "Host(`example.com`) && PathPrefix(`/api`)"
      service: my-service
  services:
    my-service:
      loadBalancer:
        servers:
          - url: "http://backend1:8080"
          - url: "http://backend2:8080"

Fabio configuration (Properties):

route add myservice /api http://backend1:8080 weight=100
route add myservice /api http://backend2:8080 weight=100

Both Traefik and Fabio are popular reverse proxy and load balancing solutions, but they cater to different use cases. Traefik offers a more comprehensive feature set and easier integration with modern infrastructure, while Fabio focuses on simplicity and performance. The choice between the two depends on specific project requirements and infrastructure complexity.

nginx

22,139

The official NGINX Open Source repository.

Pros of nginx

More mature and widely adopted, with extensive documentation and community support
Highly performant and efficient for static content serving and reverse proxying
Offers a broader range of features, including web server capabilities

Cons of nginx

Configuration can be complex, especially for dynamic routing scenarios
Less focused on service discovery and integration with modern microservices architectures
Requires manual updates to configuration files for changes in backend services

Code Comparison

nginx configuration example:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

fabio configuration example:

route add service / http://backend.service.consul/

fabio focuses on simplicity and automatic service discovery, while nginx requires more manual configuration but offers greater flexibility. fabio integrates seamlessly with Consul for service discovery, whereas nginx typically requires additional tooling or manual updates for dynamic backend changes. Both projects serve as reverse proxies, but nginx has a broader feature set as a full web server, while fabio specializes in load balancing for microservices environments.

envoy

24,693

Cloud-native high-performance edge/middle/service proxy

Pros of Envoy

More extensive feature set, including advanced traffic management and observability capabilities
Stronger community support and wider adoption in large-scale production environments
Better performance and scalability for high-traffic scenarios

Cons of Envoy

Steeper learning curve and more complex configuration
Higher resource consumption, especially for smaller deployments
Requires more setup and maintenance effort compared to simpler alternatives

Code Comparison

Fabio configuration example:

route add service-a /api/service-a service-a:8080
route add service-b /api/service-b service-b:8080

Envoy configuration example:

static_resources:
  listeners:
    - address:
        socket_address:
          address: 0.0.0.0
          port_value: 8080
  clusters:
    - name: service_a
      connect_timeout: 0.25s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      hosts:
        - socket_address:
            address: service-a
            port_value: 8080

Envoy offers more granular control and advanced features, but requires more verbose configuration. Fabio provides a simpler setup for basic routing scenarios.

haproxy

4,812

HAProxy Load Balancer's development branch (mirror of git.haproxy.org)

Pros of HAProxy

More mature and battle-tested, with a longer history of production use
Highly performant and efficient, capable of handling massive traffic loads
Extensive documentation and large community support

Cons of HAProxy

Configuration can be complex and less intuitive for beginners
Less native support for modern service discovery and dynamic routing

Code Comparison

HAProxy configuration example:

frontend http_front
   bind *:80
   default_backend http_back

backend http_back
   balance roundrobin
   server server1 127.0.0.1:8000 check
   server server2 127.0.0.1:8001 check

Fabio configuration example:

route add service / http://localhost:8000/
route add service / http://localhost:8001/

Fabio offers a simpler configuration syntax, focusing on service-oriented routing. HAProxy provides more granular control but requires more detailed configuration. Both projects serve as load balancers and reverse proxies, but Fabio is designed with a focus on microservices and cloud-native environments, while HAProxy is a more general-purpose solution with broader applicability across various infrastructure setups.

mesh

2,022

Traefik Mesh - Simpler Service Mesh

Pros of Traefik Mesh

More advanced service mesh features, including mTLS and traffic splitting
Better integration with Kubernetes and cloud-native ecosystems
Active development and regular updates

Cons of Traefik Mesh

Steeper learning curve and more complex configuration
Higher resource consumption due to additional features
Less suitable for simpler routing scenarios

Code Comparison

Traefik Mesh configuration (CRD):

apiVersion: traefik.containo.us/v1alpha1
kind: TraefikService
metadata:
  name: my-service
spec:
  weighted:
    services:
      - name: service-v1
        weight: 80
      - name: service-v2
        weight: 20

Fabio configuration:

route add my-service /api strip=/api service-v1:8080 weight 80
route add my-service /api strip=/api service-v2:8080 weight 20

Both examples demonstrate traffic splitting between two service versions, but Traefik Mesh uses Kubernetes Custom Resource Definitions (CRDs) for configuration, while Fabio uses a simpler text-based format.

linkerd2

10,567

Ultralight, security-first service mesh for Kubernetes. Main repo for Linkerd 2.x.

Pros of Linkerd2

More comprehensive service mesh solution with advanced features like mTLS, traffic splitting, and observability
Designed for Kubernetes-native environments, offering seamless integration
Active community and regular updates, backed by the CNCF

Cons of Linkerd2

Higher complexity and resource overhead compared to Fabio
Steeper learning curve for implementation and management
May be overkill for simpler routing needs

Code Comparison

Fabio configuration example:

route add service / http://service.local/

Linkerd2 configuration example:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service
spec:
  routes:
    - name: my-route
      condition:
        method: GET
        pathRegex: /api/v1/.*

Fabio focuses on simple, straightforward routing configurations, while Linkerd2 offers more granular control over traffic management and service-to-service communication within a Kubernetes cluster. Fabio is lightweight and easy to set up, making it suitable for simpler use cases. Linkerd2, on the other hand, provides a full-featured service mesh solution with advanced capabilities, but requires more resources and expertise to implement and manage effectively.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Notes

From release 1.6.1 onward, the minimum golang version supported is 1.16.
From release 1.6.0 onward, metrics backend statsd is no longer supported. statsd_raw works similarly, though it actually resets counters appropriately. If you are using datadog, you should consider using the new dogstatsd backend, which has support for tags now. Graphite histogram functionality has changed slightly since switching to gokit framework, so something to be aware of. Prometheus functionality is now supported natively.
From release 1.5.15 onward, fabio changes the default GOGC from 800 back to the golang default of 100. Apparently this made some sense back in the golang 1.5 days, but with changes introduced with golang 1.12 and others, this is probably no longer a very good default. This is still configurable, as always, but the new default should make the most sense for most users.
From release 1.5.14, release hashes are signed with a new PGP key. See details here.
From release 1.5.14 onward, fabio binary releases are compiled with golang 1.15+.
This means that the fabio will no longer validate upstream https certificates that do not have SAN extensions matching the server name. This may be a concern if fabio is communicating with https backends with misconfigured certificates. If this is a problem, you can specify tlsskipverify=true on the route.

fabio is a fast, modern, zero-conf load balancing HTTP(S) and TCP router for deploying applications managed by consul.

Register your services in consul, provide a health check and fabio will start routing traffic to them. No configuration required. Deployment, upgrading and refactoring has never been easier.

fabio is developed and maintained by The Fabio Authors.

It powers some of the largest websites in Australia (gumtree.com.au) and Italy (www.kijiji.it). It delivers 23.000 req/sec every day since Sep 2015 without problems.

It integrates with Consul, Vault, Amazon ELB, Amazon API Gateway and more.

It supports (Full feature list)

TLS termination with dynamic certificate stores
Raw TCP proxy
TCP+SNI proxy for full end-to-end TLS without decryption
HTTPS+TCP+SNI proxy for TCP+SNI with HTTPS fallback
TCP dynamic proxy
HTTPS upstream support
Websockets and
SSE
Dynamic reloading without restart
Traffic shaping for "blue/green" deployments,
Prometheus,
Circonus,
Graphite,
StatsD,
DataDog for metrics,
WebUI and
Advertising BGP anycast addresses on non-windows platforms.

Watch Kelsey Hightower demo Consul, Nomad, Vault and fabio at HashiConf EU 2016.

The full documentation is on fabiolb.net

Getting started

Install from source, binary, Docker or Homebrew.

# go 1.15 or higher is required
go install github.com/fabiolb/fabio@latest          (>= go1.15)

brew install fabio                                  (OSX/macOS stable)
brew install --devel fabio                          (OSX/macOS devel)

docker pull fabiolb/fabio                           (Docker)

https://github.com/fabiolb/fabio/releases           (pre-built binaries)

Register your service in consul.

Make sure that each instance registers with a unique ServiceID and a service name without spaces.
Register a health check in consul as described here.

By default fabio only watches services which have a passing health check, unless overridden with registry.consul.service.status.
Register one urlprefix- tag per host/path prefix it serves, e.g.:

# HTTP/S examples
urlprefix-/css                                     # path route
urlprefix-i.com/static                             # host specific path route
urlprefix-mysite.com/                              # host specific catch all route
urlprefix-/foo/bar strip=/foo                      # path stripping (forward '/bar' to upstream)
urlprefix-/foo/bar proto=https                     # HTTPS upstream
urlprefix-/foo/bar proto=https tlsskipverify=true  # HTTPS upstream and self-signed cert

# TCP examples
urlprefix-:3306 proto=tcp                          # route external port 3306

Make sure the prefix for HTTP routes contains at least one slash (/).

See the full list of options in the Documentation.

Start fabio without a config file (assuming a running consul agent on localhost:8500) Watch the log output how fabio picks up the route to your service. Try starting/stopping your service to see how the routing table changes instantly.
Send all your HTTP traffic to fabio on port 9999. For TCP proxying see TCP proxy.
Done

Author and Founder

Frank Schroeder @magiconair

Maintainers

Contributors

This project exists thanks to all the people who contribute. [Contribute].

License

See LICENSE for details.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot