What's the practical difference between Default and Serverless service mode?

Default mode expects a traditional, persistently-connected SignalR backend server (like an ASP.NET Core app using the SignalR SDK) that maintains its own connection to the service. Serverless mode is designed for Azure Functions-based backends that don't maintain a standing connection, instead reacting to events via the upstream webhook pattern and using the SignalR Functions bindings, choosing the wrong mode for your actual backend architecture means connection and message routing won't work as expected.

Can a client bypass the networkACLs restriction and reach ServerConnection or RESTAPI operations from the public internet?

Not if networkACLs is configured correctly as in the example, the public network's explicit deny on ServerConnection and RESTAPI (with only ClientConnection allowed) means those operations are only reachable via the specifically-allowed private endpoint, this is enforced at the SignalR service level, not just a client-side convention, a properly configured deny genuinely blocks the request.

Does hubPattern in an upstream template scope which hub's events trigger that specific webhook?

Yes, hubPattern (along with eventPattern and categoryPattern) filters which combination of hub, event type, and category actually triggers a call to that upstream URL template, this is what lets a single SignalR resource serve multiple logically distinct hubs (orderUpdates, chat) each routing to its own appropriate backend webhook rather than all hubs sharing one undifferentiated event handler.

Azure SignalR Service Config Builder

ServerlessAzure

Build SignalR Service configs with service mode, upstream templates, CORS, network ACLs, and hub-level routing.

Azure SignalR Service Configuration

Build SignalR Service configs with service mode, upstream templates, CORS, network ACLs, managed identity, and hub-level routing.

Required Fields

nameresourceGroupsku.nameserviceModecors.allowedOrigins

{
  "name": "sigr-contoso-prod",
  "resourceGroup": "rg-realtime",
  "location": "eastus2",
  "sku": {
    "name": "Premium_P1",
    "tier": "Premium",
    "capacity": 2
  },
  "kind": "SignalR",
  "serviceMode": "Default",
  "features": {
    "enableConnectivityLogs": true,
    "enableMessagingLogs": true,
    "enableLiveTrace": false
  },
  "cors": {
    "allowedOrigins": [
      "https://app.contoso.com",
      "https://admin.contoso.com"
    ]
  },
  "upstream": {
    "templates": [
      {
        "urlTemplate": "https://func-contoso-signalr.azurewebsites.net/runtime/webhooks/signalr?code=<function-key>",
        "hubPattern": "orderUpdates",
        "eventPattern": "*",
        "categoryPattern": "connections,messages",
        "auth": {
          "type": "ManagedIdentity",
          "managedIdentityResource": "https://func-contoso-signalr.azurewebsites.net"
        }
      },
      {
        "urlTemplate": "https://func-contoso-signalr.azurewebsites.net/runtime/webhooks/signalr?code=<function-key>",
        "hubPattern": "chat",
        "eventPattern": "*",
        "categoryPattern": "connections,messages"
      }
    ]
  },
  "networkACLs": {
    "defaultAction": "Deny",
    "publicNetwork": {
      "allow": ["ClientConnection"],
      "deny": ["ServerConnection", "RESTAPI"]
    },
    "privateEndpoints": [
      {
        "name": "pe-sigr-backend",
        "allow": ["ServerConnection", "RESTAPI"],
        "deny": []
      }
    ]
  },
  "identity": {
    "type": "SystemAssigned"
  },
  "tls": {
    "clientCertEnabled": false,
    "minimumTlsVersion": "1.2"
  },
  "publicNetworkAccess": "Enabled",
  "tags": {
    "environment": "production",
    "team": "backend"
  }
}

Generated Output

Output will appear here...

What This Tool Does

Build an Azure SignalR Service configuration with serviceMode (Default for a traditional ASP.NET Core SignalR backend, Serverless for Azure Functions-based backends with no persistent server connection), upstream webhook templates routing hub events to a backend, and networkACLs providing fine-grained per-connection-type access control (ClientConnection versus ServerConnection versus RESTAPI) independently for public network access and each private endpoint. The networkACLs example demonstrates a deliberately asymmetric pattern: the public network is allowed ClientConnection but denied ServerConnection and RESTAPI, while a specific private endpoint (pe-sigr-backend) is allowed exactly the opposite, ServerConnection and RESTAPI, meaning clients can only ever connect from the public internet while the actual backend management/server operations are confined entirely to the private network path.

Technical Details

The builder validates that name, resourceGroup, sku.name, serviceMode, and cors.allowedOrigins all resolve before accepting the JSON as a valid combined SignalR service configuration; it can't verify the referenced upstream webhook URLs are reachable or that the managed identity has the correct permissions to call them, those are only confirmed when a real hub event actually triggers an upstream call.

Common Use Cases

1Setting serviceMode to Serverless when the backend is Azure Functions rather than a persistently-running ASP.NET Core server, since Serverless mode changes how SignalR routes connection lifecycle events to a backend that doesn't maintain a standing connection the way Default mode's upstream expects.
2Configuring networkACLs so public network access is scoped to ClientConnection only, while ServerConnection and RESTAPI (the higher-privilege operations for sending messages and managing the hub) are confined to a specific private endpoint, preventing any backend-level operation from being reachable over the public internet.
3Using upstream.templates with a hubPattern scoping different webhook URLs to different hubs (orderUpdates versus chat), so events from logically separate real-time features route to their own dedicated backend handlers rather than one shared, undifferentiated webhook.
4Using ManagedIdentity auth on an upstream template so the webhook call to the backend Function authenticates via Azure AD-backed managed identity rather than an embedded, rotatable-only-by-hand function key or shared secret.

Common Questions

What's the practical difference between Default and Serverless service mode?: Default mode expects a traditional, persistently-connected SignalR backend server (like an ASP.NET Core app using the SignalR SDK) that maintains its own connection to the service. Serverless mode is designed for Azure Functions-based backends that don't maintain a standing connection, instead reacting to events via the upstream webhook pattern and using the SignalR Functions bindings, choosing the wrong mode for your actual backend architecture means connection and message routing won't work as expected.
Can a client bypass the networkACLs restriction and reach ServerConnection or RESTAPI operations from the public internet?: Not if networkACLs is configured correctly as in the example, the public network's explicit deny on ServerConnection and RESTAPI (with only ClientConnection allowed) means those operations are only reachable via the specifically-allowed private endpoint, this is enforced at the SignalR service level, not just a client-side convention, a properly configured deny genuinely blocks the request.
Does hubPattern in an upstream template scope which hub's events trigger that specific webhook?: Yes, hubPattern (along with eventPattern and categoryPattern) filters which combination of hub, event type, and category actually triggers a call to that upstream URL template, this is what lets a single SignalR resource serve multiple logically distinct hubs (orderUpdates, chat) each routing to its own appropriate backend webhook rather than all hubs sharing one undifferentiated event handler.

Expert Tips

TIP

Match serviceMode to your actual backend architecture, Default for a persistently-connected server, Serverless for Functions-based, picking the wrong mode for your architecture breaks connection lifecycle handling in ways that aren't always immediately obvious from a quick smoke test.

TIP

Design networkACLs as a genuinely asymmetric split between what the public internet can do (client connections only) and what only the private network can do (server operations, REST API), this is a real security boundary worth getting right, not just a default to leave permissive.

TIP

Prefer ManagedIdentity auth on upstream webhook templates over an embedded function key where the backend supports it, removing a long-lived, manually-rotated secret from the SignalR configuration in favor of Azure AD-backed identity.

Related Learning Guides

Functions Hosting Plans22 min read
Service Bus vs Event Grid vs Event Hubs24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.