Can YARP configuration be stored in SQL Server? Yes!

In my previous post, I introduced Microsoft's Yet Another Reverse Proxy (YARP) project and its configuration model.

One interesting question that often follows is: does the configuration really have to come from appsettings.json?

The answer is simply: no, it does not.

In fact, YARP's routes and clusters can come from any source, provided your application can build the required configuration objects.

For smaller environments, JSON configuration is perfectly fine. But in larger deployments, storing proxy configuration in SQL Server can make administration much easier.

Imagine a simple table:

CREATE TABLE ReverseProxyRoutes
(
    RouteId nvarchar(100),
    Path nvarchar(200),
    ClusterId nvarchar(100)
)

A small ADO.NET helper can then load the rows:

using Microsoft.Data.SqlClient;

List<RouteConfig> routes = new();
using SqlConnection connection =
    new SqlConnection(connectionString);
connection.Open();

using SqlCommand command = new(
  "SELECT RouteId, Path, ClusterId FROM ReverseProxyRoutes",
  connection);

using SqlDataReader reader = command.ExecuteReader();

while (reader.Read())
{
    routes.Add(new RouteConfig
    {
        RouteId = reader.GetString(0),
        Match = new RouteMatch
        {
            Path = reader.GetString(1)
        },
        ClusterId = reader.GetString(2)
    });
}

The same idea applies to cluster configuration:

CREATE TABLE ReverseProxyClusters
(
    ClusterId nvarchar(100),
    DestinationAddress nvarchar(500)
)

Those rows can be converted into YARP's ClusterConfig objects before the proxy starts.

The benefit is that administrators can update routing without modifying deployment packages or editing configuration files on servers.

Tip: if you choose database-backed configuration, also think about how configuration changes are refreshed. For example:

• reload configurations every few minutes
• reload after an administrator saves changes
• listen for SQL Server notifications
• restart the application after configuration updates.

Another consideration is validation. A malformed route in a database table can affect the running proxy just as easily as an invalid JSON configuration file.

One approach is to separate editing from publishing. Administrators modify draft configuration, validation is performed, and only validated routes become active.

Because YARP is built on ASP.NET Core, the configuration source is largely your own choice. SQL Server, REST APIs, Azure App Configuration, or even another internal service can all act as the source of truth.

Using SQL Server is certainly not required, but it demonstrates one of YARP's strengths: routing configuration does not have to be tied to static files.

Happy proxying!