---
title: "Single and Multiple Lasernet Config Servers - General Information"
slug: "single-and-multiple-configuration-servers"
description: "There are advantages and disadvantages when hosting builds either on a single server or on multiple configuration servers. Read for more info."
updated: 2026-09-28T07:46:19Z
published: 2026-09-28T07:46:19Z
canonical: "kb.lasernetgroup.com/single-and-multiple-configuration-servers"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.lasernetgroup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Single and Multiple Lasernet Config Servers

You can host Lasernet Core configurations on a single or multiple Lasernet Config Servers. However, each of these approaches has advantages and disadvantages.

## Option 1 – Single Config Server (Single Configuration)

In Lasernet 9, Lasernet Core 10, and Lasernet Core 11, you can host a configuration on a single Lasernet Config Server and use that configuration for multiple environments/servers. All changes are made to that configuration, which can then be deployed to different Lasernet Core environments/servers as needed.

The advantage of this approach is that users do not need to export and import changes between configurations or configurations between Config Servers.

The disadvantages arise when multiple users make changes to the configuration simultaneously, because it is crucial that a Lasernet user does not commit untested changes that are not ready to be deployed to production environments/servers. When committing changes, users must select only approved and tested configuration changes to be included in the new configuration revision.

Use **Patch** (Lasernet Developer 10) or **Deploy Workspace** (Lasernet Developer 11) to send any changes made to a form to a Test server/environment. Then, use **Commit** to create a new revision only after testing and approving the form changes. Finally, send the new configuration revision to a Production environment/server by using **Deploy**.

If you commit untested changes, you must ensure you do not deploy that commit to a Production environment/server, as it includes changes not approved for production use.

Using a single Config Server to support multiple environments (such as Test and Production) can work if you have a clear process that controls when changes are committed.

![A diagram explaining the first type of configuration.](https://cdn.document360.io/c831ef63-c6b3-48ee-b443-3e33644e4e2e/Images/Documentation/option 1(1).png)

> [!NOTE]
> Note
> 
> Environment variables (either system variables or Lasernet JobInfo variables) can be used in this setup to control parts of the Lasernet configuration to avoid issues when deploying to multiple servers.

## Option 2 – Multiple Configuration Servers

Each environment/server (such as Test and Production) has a dedicated Config Server. Users can export and import configurations between the Config Servers. Deployment from each Config Server to its corresponding environment/server is straightforward, as each Config Server and Lasernet Core environment/server pair is entirely separate.

![A diagram explaining the second type of configuration.](https://cdn.document360.io/c831ef63-c6b3-48ee-b443-3e33644e4e2e/Images/Documentation/option 2.png)

## Option 3 – Single Config Server (Configuration Variants for Each Environment/Server)

The setup consists of a single Lasernet Config Server that hosts environment/server-specific variants of each configuration. For example, if the Lasernet Core configuration is known as Configuration1 and the Lasernet Core system has two environments (Test and Production), the Config Server hosts two configurations: Configuration1-Test and Configuration1-Production.

Each configuration is deployed only to the corresponding environment/server. In other words, the Configuration1-Test configuration is deployed only to the Test Lasernet Core environment/server.

Changes are committed only to the appropriate configuration. For example, if a change to a form requires testing, that change is made in a new revision of the Configuration1-Test configuration. Then, that configuration is deployed to the Test environment/server.

After the change is approved through testing, that change is exported from the Configuration1-Test configuration and imported into the Configuration1-Production configuration. Now that the Configuration1-Production configuration contains the tested change, it can be deployed to the Production Lasernet Core environment/server.

Because you have environment/server-dedicated configurations, you do not have to tightly control when changes are committed to each environment/server.

![A diagram explaining the third type of configuration.](https://cdn.document360.io/c831ef63-c6b3-48ee-b443-3e33644e4e2e/Images/Documentation/option 3(1).png)