Host Configuration Files
What lives in each component's appsettings.json — and why there is so little in it.
Most Infohub configuration lives in the database, not in files. That is a deliberate choice, and it is why an administrator arriving from other systems goes looking for a large configuration file and cannot find one.
Each component does keep a small appsettings.json beside its executable, holding only the two things that cannot live in the database: how to reach the database, and how much to log before the database logging is running.
Editing these files is not how you configure Infohub. Engines, servers, connections, consumers, time schemes and everything else are configured in Flow Config and stored in the instance database — see The Deployment View. If you are editing a file to change Infohub's behaviour, you are almost certainly in the wrong place.
What each component holds#
| Component | Contents |
|---|---|
| Flow Config | ConnectionStrings:FlowEntities |
| Data Engine | ConnectionStrings:FlowEntities |
| Message Engine | ConnectionStrings:FlowEntities |
| Flow Server | Logging:LogLevel:Default, AllowedHosts |
| Flow Platform | Logging — IncludeScopes, and separate Console and Debug levels |
| Flow Bootstrap | Logging:LogLevel:Default, Logging:LogLevel:Microsoft.Hosting.Lifetime |
Note which components have a connection string and which do not. Flow Server and Flow Platform are reached through the Bootstrap and the deployment configuration rather than pointing themselves at the database.
The connection string#
FlowEntities is an Entity Framework connection string, not a plain SQL Server one. It wraps the real connection inside a provider connection string= section, alongside the metadata resource paths:
metadata=res://*/Core.Flow.csdl|res://*/Core.Flow.ssdl|res://*/Core.Flow.msl;
provider=Microsoft.Data.SqlClient;
provider connection string="data source=localhost;initial catalog=FIP;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"
Three things to know before editing it:
- The
metadata=portion must stay exactly as it is. It names resources compiled into the assembly. Replacing the whole value with an ordinary SQL connection string is the most common way to make a component fail to start. - Only the inner
provider connection stringis yours to change — server, catalogue and authentication. MultipleActiveResultSets=Trueis required. Removing it produces intermittent failures under load rather than a clean error at startup.
Changing where a component points is normally done through Flow Config's connect and registration flow rather than by hand — see Instance Lifecycle.
Log levels#
The Logging section controls what a component writes through the .NET logging pipeline — which is mostly startup, hosting and framework messages. Infohub's own operational logging goes to the Infohub log, which is configured in Flow Config and read as described in Reading Infohub Logs.
That distinction matters when something fails before Infohub logging is available. A component that will not start writes here and nowhere else, so this is the file to raise when diagnosing a startup failure:
{ "Logging": { "LogLevel": { "Default": "Information" } } }
Accepted values, least to most verbose: Critical, Error, Warning, Information, Debug, Trace.
The shipped defaults differ by component — Server and Platform default to Warning, Bootstrap to Information — so do not read a quiet Server log as evidence that nothing happened.
Flow Platform configures Console and Debug sinks separately. Raising only one leaves the other at its own level, which is the usual reason a level change appears to have had no effect.
Put the level back. Debug and Trace are for diagnosis, not for running. Left on, they produce very large logs and measurably slow a busy host.
The Bootstrap port#
Infohub's components find each other through the Bootstrap, which listens on port 4501 by default at the base path /flow-software/flow. Flow Config talks to it, and so does every platform.
Where a firewall or an IT policy will not allow 4501, the port can be changed — but it has to be changed in both places, and that is where this usually goes wrong.
| Change | Where | Affects |
|---|---|---|
| The Bootstrap service's listening port | The -port <number> argument the service is started with |
What the Bootstrap listens on |
| The port Flow Config connects to | System properties in Flow Config | What Config, and the instance, expect to reach |
Changing one without the other leaves Config talking to a port nothing is listening on.
Every component must agree. The port has to be the same across all Infohub components, and that matters most in a multi-platform deployment where a mismatch only shows up on the one host that was missed. After changing it, restart the Bootstrap service and redeploy the Platform.
If you are following an older procedure. Documentation for earlier versions describes creating a Bootstrap.settings file containing {"port":80} in the Bootstrap folder. That is not how 7.2.0 reads its port. In this release the value comes from the -port command-line argument, defaulting to 4501, and no such settings file is consulted. Set the argument on the service instead.
AllowedHosts#
Flow Server ships with AllowedHosts: "*", accepting any Host header. Restricting it to the host names your server is actually reached by is a reasonable hardening step where Flow Server is exposed beyond a trusted network — alongside TLS, covered in HTTPS and Certificates.
After editing#
Restart the component. These files are read at startup; nothing re-reads them while running. Change the file, restart the service, then confirm the component came back up rather than assuming it did.
Diagnosing#
| Symptom | Likely cause |
|---|---|
| A component exits immediately at startup | Malformed appsettings.json, or the metadata= portion of the connection string was replaced |
| Starts, then cannot reach the database | The inner provider connection string is wrong, or the service account has no rights to that catalogue |
| Intermittent query failures under load | MultipleActiveResultSets=True was removed |
| A log level change did nothing | The component was not restarted, or on Platform only one of Console/Debug was raised |
| Nothing in the log for a failed start | Level is at the shipped Warning default; raise it to Information and restart |
| Editing a file did not change Infohub's behaviour | That setting lives in the database — configure it in Flow Config |