Component Settings

Where the metrics history goes#

Each host keeps a short history of its own metrics on disk. It is written to a Metrics folder inside the Logs path, and there is no key to put it anywhere else.

That is the point of the arrangement: diagnostics are one folder. Ask for a host's logs and the metrics history comes with them, without anyone having to remember a second location. Relocating Logs moves both together, which is the relocation people actually make.

The Instance Info tab shows the resolved path and marks it Derived from Logs, so it is clear the row is telling you where to look rather than offering a setting to change. A Metrics value left in an older configuration file or launch argument is ignored.

You can edit most of this from the interface#

Every component now exposes its own settings.config through a settings editor in its interface, built from a schema the component publishes rather than from a hand-written form. Atlas, Bridge, Collector, Connect, Explorer, Historian, Pulse and the Service Starter all have one.

It is the safer way to make a change. The editor knows each setting's type and permitted values, and a save deep-merges your edits into the file on disk rather than rewriting it, so comments and any settings the editor does not show are left exactly as they were.

Two things it deliberately will not do:

• It never shows you a secret. ClientSecret and its equivalents are excluded from the read, so the editor cannot display one and cannot round-trip one back.
• It does not expose Pulse:Gage:Guardrails. That section decides how far the AI assistant's file and command tools may reach, and widening it from a browser is not a decision the editor should make easy. Edit it in the file, deliberately. It takes effect on the agent's next tool call, with no restart.

Everything below describes the file itself, which is still there and still authoritative. Use it when you are editing offline, scripting a deployment, or changing something the editor holds back.

Your instance has a name#

Each host also carries an Instance Info tab showing what this installation is: its name, description, serial and licence state, with the entitlements it holds and how much of each it is using. The name and description are yours to set, and they are the answer to "which install am I looking at" across an estate.

That identity is not in settings.config. It lives in the host's own state file, beside the licensing serial. Bridge and Connect used to carry Bridge:Id / Bridge:Name and Connector:Id / Connector:Name in their settings files; those keys are gone, and a copy left in an older file is not read. What a connector advertises on the wire is unchanged, so nothing downstream notices the move.

See Licensing and Entitlements for what the licence section of that tab is telling you.

Where is settings.config?#

Each Timebase component requires the JSON file settings.config to configure its logging levels, network settings, and authentication parameters.

By default, this file can be found at the following paths:

Windows - C:\Program Files\Flow Software\Timebase\<Component>\Settings

Docker - \<Component>\Settings (which should be in a Docker volume)

What does settings.config contain?#

The settings.config file contains the following:

{
  "DetailedErrors": true,

  "Serilog": {
    "MinimumLevel": {
      "Default": "Warning",
      "Override": {
        "Timebase.Pulse": "Information"
      }
    }
  },

  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://0.0.0.0:4541"
      } ,
       "Https": {
        "Url": "https://0.0.0.0:4542",
        "Certificate": { 
          "Subject": "localhost", 
          "Store": "Root", 
          "Location": "CurrentUser", 
          "AllowInvalid": "true" 
      } 
     }
    }
  }
}

Detailed Errors#

"DetailedErrors": true,

Set this to true to display more comprehensive error messages, which will help you and our support team troubleshoot problems more effectively.

Serilog logging#

This section controls the logging behavior for different namespaces within the component.

"Serilog": {
    "MinimumLevel": {
      "Default": "Warning",
      "Override": {
        "Timebase.Pulse": "Information"
      }
    }
  },

The Default logging level is set to Warning to avoid flooding the logs with unnecessary messages. Relevant namespaces, like Timebase.Pulse or Timebase.Historian, can override the default Warning. We have set these to Information to provide informative logs relevant to the component.

Other log levels include:

• Error, Warning, Information, Debug, Verbose

Logs can be viewed in various places:

• Console
• Status page on the component's UI
• Text files in the component's Log path

Kestrel network settings#

When the Timebase components run, they communicate with each other, and external client apps, via a Web API. The startup of this Web API is controlled by these Kestrel settings:

  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://0.0.0.0:4541"
      } ,
       "Https": {
        "Url": "https://0.0.0.0:4542",
        "Certificate": { 
          "Subject": "localhost", 
          "Store": "Root", 
          "Location": "CurrentUser", 
          "AllowInvalid": "true" 
      }
  }

• Endpoints: Defines the addresses where the Web API will listen for network requests
  • "Http": { "Url": "http://0.0.0.0:4541" }: This means that the Web API will listen for HTTP requests on all network addresses (0.0.0.0) on port 4541. This makes the application accessible from any IP address.
• Endpoints: How to add an HTTPS endpoint.

• The certificate is stored on the server, and Kestrel is configured to use it. In production, a TLS certificate must be explicitly configured. At a minimum, a default certificate must be provided.

  "Kestrel": {
    "Endpoints": {
      "Https": { 
        "Url": "https://0.0.0.0:4512", 
        "Certificate": { 
          "Subject": "<subject; required>", 
          "Store": "<certificate store; required>", 
          "Location": "<location; defaults to CurrentUser>", 
          "AllowInvalid": "<true or false; defaults to false>" 
      }
    }
  }

• Endpoint names are case-insensitive. For example, HTTPS and Https are equivalent.
• The Url parameter is required for each endpoint.
• The Certificate section is optional. If the Certificate section isn't specified, the defaults defined in Certificates:Default are used. If no defaults are available, the development certificate is used. If there are no defaults and the development certificate isn't present, the server throws an exception and fails to start.
• The Certificate section supports multiple certificate sources. Please see Kestrel Certificate Settings for other examples on how to configure certificate locations
• Any number of endpoints may be defined in Configuration, as long as they don't cause port conflicts.

Pulse connection settings#

Every component carries a Pulse section, and everything to do with Pulse lives inside it: where Pulse is, the certificate relationship, the assistant, and this component's own OAuth client under Pulse:Auth. One section, one place to change the address.

Within it, Pulse:Auth decides who may call this component, while Pulse:Cert and Pulse:Gage decide what this component gets from Pulse - certificates and language models.

"Pulse": {
  "Host": "localhost",
  "Port": 4542,
  "UseTls": true,
  "Cert": {
    "Enabled": true
  },
  "Gage": {
    "Enabled": true,
    "Agents": {}
  }
}

• Host, Port and UseTls say where Pulse answers. They default to localhost, 4542 and true.

Certificate management#

Pulse:Cert:Enabled turns on automatic certificate management. It is true by default, and with it on the component:

• generates a self-signed certificate on first start, so it can serve HTTPS straight away
• asks Pulse for a signed replacement, and installs Pulse's root certificate authority into the machine trust store, which is what lets components trust each other
• reloads the certificate in place when Pulse issues a renewal, with no restart

Set it to false when you want to supply your own certificate. You are then responsible for the whole Kestrel:Endpoints:Https:Certificate block described in the Kestrel section above.

Language models#

Pulse:Gage:Enabled lets the component reach Pulse's Gage gateway for the language models its AI harness uses.

No component holds a model API key of its own. The provider and its key are registered once in Pulse, and every component draws from that catalogue - so a component with Gage:Enabled set to true still has no assistant until a provider exists in Pulse. See Configuring Gage LLM providers and models.

Authorization settings#

Depending on the Timebase component, the following authorization settings are required:

Pulse#

Pulse is an OAuth 2.0 and OpenID Connect identity provider, so it issues the tokens every other component presents. Each token carries an issuer, the iss claim, naming the Pulse that issued it. The other components read the issuer from Pulse itself and accept only tokens that carry it.

"Auth": {
  "PublicAddress": "https://pulse.example.com:4542"
}

• PublicAddress is where browsers and clients reach Pulse. The issuer is derived from it, as this address plus /auth, so there is no issuer to set: standard OpenID Connect and MCP clients load Pulse's discovery document from the issuer, and it has to be an address that works. Setting up Timebase Pulse has the details.
• Empty is fine on a single machine: the issuer then comes from Pulse's own HTTPS endpoint, for example https://localhost:4542/auth.

Every component except Pulse#

Every other component authenticates against Pulse rather than issuing tokens, so they all take the same shape:

"Pulse": {
  "Host": "localhost",
  "Port": 4542,
  "UseTls": true,
  "Auth": {
    "Enabled": true,
    "ClientId": "<Component>",
    "ClientSecret": "<YourComponentClientSecret>"
  }
}

• Pulse:Host, Pulse:Port, Pulse:UseTls - where Pulse is. This is also the identity provider address: there is no separate one to keep in step.
• Enabled - true or false. Set to true if you want to secure your component. This setting is useful if you want to turn authentication off during testing, and not have to delete the whole Auth section.
• ClientId - must reference a configured client in Pulse
• ClientSecret - must be the Client Secret of the specified ClientId

Ports and client IDs by component#

The values each component ships with. Ports are the defaults in its Kestrel:Endpoints section, and the client ID is the value it sends to Pulse, which must match a client registered there.

Every component ships secured. Each one needs a client registered in Pulse under the Client ID in the table, and that client's secret written into its Pulse:Auth:ClientSecret, before it will accept requests. Plan for that as part of the install rather than after it - see Pulse OAuth clients.

Setting Pulse:Auth:Enabled to false is for a local trial, never for a deployment. Some components lose function with it off rather than merely becoming open: Atlas does not offer its assistant at all, because Gage needs a caller it can identify and meter.