Timebase 2.0 Release Notes

Version History#

2.0

Download Version 2.0#

Release date: November 5, 2026

Docker images: every component is published on Docker Hub under the timebase organization with the tag latest; each release also carries its own version tag, such as 2.0.0, for pinning. Pull them with the Compose file in Start Here for Docker rather than one at a time.

One Windows installer carries every component; choose the ones you want during setup.

From a historian to a platform

Timebase 2.0 is the largest release since 1.0. The Historian, Collector, Explorer and Pulse you know are joined by three new components: Atlas models your plant as a knowledge graph, Connect brings data from historians, databases, OPC UA servers and HTTP APIs into that model, and Bridge publishes the result out to SQL Server, Kafka, MQTT, Snowflake and other targets. Gage, the AI harness, ships inside every component and reaches its language models through Pulse, which has grown from identity provider and certificate authority into the gateway for licensing and AI as well. Timebase 2.0 runs on .NET 10 and ships as a single Windows installer and a matched set of Docker images.

New components#

Atlas#

Atlas is where data in other systems becomes a typed property of a named asset: something you can ask questions about rather than a tag you have to go and find.

• Domain modeling - describe your plant as entity types, properties, relationships and data types, then expand them into real instances with instance maps that bind each property to a live source, a fixed value or a calculation. See Introduction to Domain Modeling.
• Libraries - shared vocabularies that any domain can import. Atlas ships atlas-core, atlas-common, atlas-templates and an ISA-95 common library, and you can build and version your own. See Atlas Libraries.
• Git-backed authoring - every domain and library lives on a branch in a Git repository Atlas manages for you, with draft sessions, publishing, branch comparison and merge. See How Atlas Uses Git.
• Compile and query - a compiled domain is a World you query with openCypher and subscribe to live over the value hub. See Querying with Cypher and the openCypher Query Reference.
• Validation - every rule Atlas applies to a domain, its message and the fix, is listed in the Validation Rules Reference.
• REST API and MCP - the full /api/v1 surface for domains, ontology, libraries, instance maps, compile, query and connectors, plus an authenticated MCP endpoint so outside AI tools can work with your model. See Atlas API Overview and Atlas MCP Server.

Connect#

Connect sits between Atlas and your other systems and advertises each data point as a binding path a property can be bound to. Twelve source plugins ship: Timebase Historian, AVEVA Historian, AVEVA PI System, Canary Historian, Flow Software InfoHub, CESMII i3X, OPC UA, HTTP/REST, Microsoft SQL Server, PostgreSQL, MySQL and Oracle Database. Each has its own schema-driven editor with a connection test, and a started source takes its configuration with no restart. See Connecting Data Sources and Which Data Sources Timebase Supports.

Bridge#

Bridge subscribes to compiled Atlas values and streams every change to a downstream target. Nine destination plugins ship: Microsoft SQL Server, PostgreSQL, MySQL, MQTT, Sparkplug B, Apache Kafka, Azure Event Hubs, Snowflake Snowpipe Streaming and HTTP/REST. Subscriptions are scoped to a type, an instance or a single property, with backfill, delta emits and watermarks. See Exporting Data with Bridge.

Gage, the AI harness#

Gage ships inside every component rather than as a container of its own. Each component carries its own agents and skills, serves an authenticated MCP endpoint at /mcp, and reaches its language model through Pulse, so no component holds a model API key of its own.

• Ask Gage in Atlas, with six shipped agents and a library of skills you can extend. See Ask Gage, the Atlas AI Assistant and Atlas AI Agents.
• Assistants in the Historian, Explorer and Collector, switched on through Pulse in five steps. See Quick Start: Turn On the AI Assistant.
• Your own agents and skills, authored as files and shipped with a deployment. See Authoring an Atlas Agent and Authoring an Atlas Skill.

Portal#

Portal is hosted by Flow Software and is where an installation becomes yours: create an organization, invite your team, connect the installation and licence it. Only Pulse talks to Portal, over a single outbound connection, and Pulse caches what it is told so an offline site keeps running. See Setting Up Your Organization in Portal and Licensing and Entitlements.

Pulse#

Pulse is no longer optional. Every component in 2.0 ships with authentication switched on, sends its users to Pulse to sign in, obtains its TLS certificate from Pulse, takes its licence from Pulse and reaches its language model through Pulse.

• One OAuth client per component, seeded on first start - Historian, Collector, Explorer, Atlas, Connect, Bridge and Pulse's own loopback client, each with the audiences it needs already set. You supply each component its secret once, through the component's own setup form, and it needs no restart. See Registering Timebase apps as OAuth clients in Pulse.
• Gage gateway - register LLM providers, choose the models each caller may use, and meter usage with client and user policies that record, throttle or block. See Configuring Gage LLM providers and models.
• Licensing - Pulse holds the connection to Portal and distributes licences to every component. An unlicensed install runs on a default tier for fourteen days.
• Certificate names and the browser address - Cert:Names lists the extra names a certificate must carry, and Auth:PublicAddress is where a browser is sent to sign in, so a containerised Pulse reached as pulse by its peers and as localhost by people needs no hosts-file entry. See Certificates and trust across Timebase.
• Federated sign-in - authenticate users against Microsoft Entra ID, Google, Okta, Auth0 or any OpenID Connect provider. See Pulse And OpenIDConnect (OIDC) User Authentication.

Historian#

• SQL access over PGWire - the Historian presents itself as a PostgreSQL server, so pgAdmin, psql, Python or a SQL Server linked server can read time-series data with no custom driver. It ships enabled on port 5432 with the published postgres / timebase login; change the password first. See Querying the Historian with SQL.
• MCP server - a built-in HTTP MCP endpoint for AI agents and assistants. See Historian MCP Server.
• Tag Data View and query filters - browse the raw history stored for any tag from the Historian browser, and narrow the tag grid with a simple query language. See Tag Data View and Historian Dataset Tag Query Filters.
• Metrics with the logs - every component keeps its own measurement history under its Logs folder, so one folder carries everything an operator collects for diagnostics.

Collector#

• One Collector, many instances - a single Collector service hosts several collector instances side by side (Simulator, OPC UA, MQTT, Sparkplug B, Telegraf), each with its own historian links, so one container or one Windows service serves the whole stack.
• Shipped examples, disabled - a fresh installation carries example instances whose names begin example-. They are off until you turn one on, so a new Historian is empty by design; enabling example-simulator is the quickest way to see data end to end.
• Pulse-secured data connections - a historian link can authenticate with a Pulse client credential, and the Collector's own Pulse client carries the Historian audience out of the box.

Explorer#

• Atlas as a source - alongside the Historian, Explorer can browse and trend values from a compiled Atlas domain. See Explorer Trending And Visualizations.
• Gage assistant in the Explorer interface, configured through Pulse like every other component.

Docker images#

• The images run unprivileged. Every image runs as the app user (uid 1654) rather than as root, which is what a locked-down cluster such as a Kubernetes restricted namespace requires. A volume written by a 1.x image is owned by root and has to be handed over once; the Compose files in Start Here for Docker carry a volume-init service that does it on every start. Any other deployment hands each volume over once, before starting the new images:

docker run --rm --user 0 -v <volume>:/historian timebase/historian:<tag> chown -R 1654:1654 /historian

Repeat per component with its own volume and mount path (/pulse, /explorer, /collector, /atlas, /connect, /bridge). For a bind-mounted directory on a Linux host, chown -R 1654:1654 <directory> does the same; on Kubernetes, set fsGroup: 1654 in the pod security context. A component that cannot write its volume now exits with a message naming the directory instead of crashing.

Configuration#

• Versioned configuration files - every configuration document carries the release that last wrote it, and a component migrates its own files forward on start, keeping the original beside it as a .bak. There is no separate upgrade step for configuration. See Configuration File Versions and Upgrades.
• One settings shape for every component - the Pulse connection, the component's OAuth client, certificate management and Gage all live under one Pulse section of settings.config. See Component Settings.
• Square-bracket placeholders everywhere - [Tag], [params.sensor], [instance.uri], [Num, 00]: one placeholder syntax across Collector metadata, Connect templates, Bridge destinations and Atlas instance maps.

Prerequisites#

• .NET 10 - specifically the .NET 10.0.x ASP.NET Core Runtime, Hosting Bundle. The plain runtime and the SDK are different packages and will not host the Timebase services. Docker images carry the runtime already. See Software Requirements Guide.
• Windows 10 or 11 64-bit, Windows Server 2019 or 2022 64-bit, or any host that runs Docker.
• Hardware - the documented minimum for the full stack on one machine is 4 cores and 8 GB. See Hardware Requirements Guide.

**From 1.3.x** - stop the components, run `Timebase.msi`, start them again. Each component migrates its own configuration files on first start and writes a `.bak` beside anything it changes. The component's OAuth client moved from a root `Auth` section to `Pulse:Auth`, the assistant settings moved from `Agent` to `Pulse:Gage`, and Pulse itself needs no assistant configuration at all. A migration never changes a value you set: a component that had authentication off keeps it off even though a fresh installation ships it on. The full list is under [Configuration](#configuration) above.

**From a 2.0 Beta (`2.0-rc`)** - there is no upgrade path. A configuration file written by a Beta build is refused at startup with a message naming the file. Install fresh, on a new volume or a clean machine, and rebuild what you need; models, users, clients and historized data created during Beta do not migrate.

**Pulse first** - after upgrading, sign in to Pulse at `https://<PulseAddress>:4542` as `Administrator` / `timebase`, change that password, and give each component its client secret through the component's setup form. Until a component holds its secret it cannot sign anyone in, does not receive its Pulse-signed certificate, and its assistant stays unconfigured. [Start Here for Docker](../10-overview/20-start-here-for-docker.md) and [Start Here for Windows](../10-overview/10-installer-for-windows.md) walk through it in order.

**PGWire ships enabled** with the published `postgres` / `timebase` login on a fresh Historian. Change it, or disable the listener, before the machine is reachable by anyone else.

Related articles#

• Start Here for Docker: How to Deploy and Secure Timebase 2.0
• Start Here for Windows
• Getting Started with DataOps and Knowledge Modeling (Docker)
• Timebase Components