Azure Storage Mode and a Modular Host

One Config Value, Zero Setup

The bar was set by SqlServer mode back in March: point FabrCore at a database and the host creates every Orleans table itself. Azure Storage mode had to clear that same bar. It does—reference the package, set the clustering mode, provide a connection string:

{
  "Orleans": {
    "ClusterId": "prod",
    "ServiceId": "fabrcore",
    "ClusteringMode": "AzureStorage",
    "ConnectionString": "DefaultEndpointsProtocol=https;AccountName=...;AccountKey=..."
  }
}

On startup the host provisions the clustering and reminder tables, the grain-state blob container, and the stream queues—then fails fast with a clear message if the connection string is wrong, instead of surfacing a cryptic Orleans error minutes later. Local development needs no Azure subscription at all: run Azurite and set the connection string to UseDevelopmentStorage=true.

Blobs for State, Queues for Streams—Deliberately

Azure Storage mode is not just "the SqlServer switch statement with different providers." The defaults reflect how FabrCore agents actually behave:

• Grain state lives in Blob Storage by default. Agent state carries conversation history, and conversation history grows. Azure Table entities cap out around 1 MB—a limit a chatty agent can cross in an afternoon. Blobs have no practical ceiling. Table storage remains one setting away for workloads with known-small state.
• Streams ride Azure Storage Queues by default. Localhost and SqlServer modes use in-memory streams; messages in flight are lost if a silo dies. Azure Queue streams are durable and cluster-wide, with queue names derived deterministically from your ServiceId so every silo agrees without coordination.
• Clustering, reminders, and stream pub/sub state stay in tables—small, hot, and exactly what Table Storage is good at.

Everything is tunable from an optional Orleans:AzureStorage section—GrainStorage, ContainerName, Streams, StreamQueueCount—but an empty section (or none at all) is a fully working production configuration.

The Host Goes Modular

Until now, FabrCore.Host bundled the SQL Server client, the Orleans ADO.NET providers, and the Orleans Azure Storage providers—whether you used them or not. That is over. The host now has a small provider seam, IFabrCoreOrleansProvider, and each backend lives in its own package:

The part we sweated: referencing the package is the integration. When ClusteringMode names a mode, the host discovers the matching provider assembly by convention and wires it up—no registration call required. Prefer explicit code? options.UseSqlServer() and options.UseAzureStorage() exist too, and the same seam lets you ship a provider package of your own.

Why This Shape

Slimmer dependency graphs are the obvious win: a host on SQL Server no longer downloads the Azure SDK, and an Azure host no longer carries Microsoft.Data.SqlClient. The quieter win is architectural—clustering, persistence, reminders, and streaming for each backend now live behind one interface with one contract, instead of three switch statements spread across the host. Localhost mode itself is just the built-in implementation of that same interface. New backends—yours or ours—are additive packages, not core surgery.

FabrCore's deployment story now spans the whole arc: Localhost on your laptop, SqlServer on your own metal or Kubernetes, AzureStorage when you want managed infrastructure with nothing to install. Same agents, same config shape, one line changed.