Server Layout

    Server Layout

    To help you determine the best server layout, look over the diagrams below and determine which layout works best for your dev, staging and production environments.

    Each layout will require FusionAuth App, Search Engine and a relational database.

    The FusionAuth services are separated because as you will see in the diagrams below they may not all run on the same server, and each component can be horizontally scaled separately. The FusionAuth Search is Elasticsearch and FusionAuth will handle the cluster configuration when multiple instances are installed based upon the provided configuration. See the Configuration reference for additional detail.

    After you have selected a desired server layout, see the installation links below for each service.

    Single server

    One Server

    This configuration uses a single server to host all of the components for FusionAuth including the relational database. In this deployment model there is no service redundancy and there is a risk of resource contention. For this reason this model should be limited to the following purposes:

    • Development servers or workstations

    • QA / Staging environments

    • Small production deployments

    Two servers with external database

    Two servers with an external database

    This configuration uses a separate server to host the relational database. The method for configuring this database is outside the scope of this guide but a general guideline would be to provide some sort of storage redundancy or clustering capability to ensure a high level of availability and performance.

    Each FusionAuth service is redundant and running on a separate server, this configuration provides basic redundancy.

    When more than one FusionAuth Search is running and configured properly these Elasticsearch nodes will cluster and duplicate each the entire search index by replicating shards between nodes.

    In this scenario FusionAuth should be placed behind a load balancer to utilize both services equally. Prior to version 1.19.0 session pinning should be utilized to support stateful sessions to FusionAuth. API connections to the FusionAuth App are stateless and do not require session pinning. All URLs beginning with /api/ will be API requests and should not be session pinned. In version 1.19.0 this requirement was removed and session pinning is no longer required. This configuration is best suited for the following purposes:

    • Staging environments

    • Production deployments

    Horizontally Scaled with external database

    Horizontally scaled with an external database

    This configuration uses separate servers to host FusionAuth App, FusionAuth Search and the database. This is a theoretical example of scaling each service individually. This configuration will provide the most flexibility and availability to FusionAuth.

    The details regarding load balancing requests and session pinning (when applicable) is the same as the previous example. This highly flexible and performance oriented configuration is best suited for the following purposes:

    • Staging environments suitable for load testing

    • Production environments

    Feedback

    How helpful was this page?

    See a problem?

    File an issue in our docs repo

    Have a question or comment to share?

    Visit the FusionAuth community forum.