Changelog

We have added quick access buttons to help you navigate to your Dashboard 2.0 UI in a single click.

Dashboard button is displayed alongside the Open Editor button when an instance has @flowfuse/node-red-dashboard installed.

Click the link to learn more about Flowfuse Dashboard 2.0

Two weeks ago, we introduced auto snapshots for devices to help ensure you can always rollback to a previous version of your Node-RED flows. We're extended that ability to the hosted Node-RED instances as well.

Whenever you deploy a change to the flows, a snapshot will be taken automatically. We'll keep the last 10 auto-generated snapshots on a first-in, first-out basis. Older auto-generated snapshots will be automatically cleaned up for you - unless they are marked as a target snapshot for your devices.

Click the following links to learn more about instances and snapshots.

Included in the v2.1.0 release the Helm Chart now uses 14.10.0-debian-11-r30 tag of the Bitnami PostgreSQL container.

This container tag includes images for both AMD64 and ARM64 allowing FlowFuse to be deployed to now fully ARM64 based Kubernetes clusters when using local PostgreSQL database.

FlowFuse V2.1 introduces Auto Snapshots for your Application Assigned Devices.

When you deploy a change to the device flows, a snapshot will be taken automatically.

The last 10 Auto Snapshots will be kept on a first in first out basis. Older Auto Snapshots will be automatically cleaned up for you.

Click the following links to learn more about devices and snapshots.

Starting today, we have introduced a simplification of the pricing structure for devices on FlowFuse Cloud, effective immediately. All information is available on our pricing page. The new pricing scheme is as follows:

• Starter Tier: No change
• Teams Tier: Devices are now priced at $25 each.
• Enterprise Tier: Devices are priced at $50 each.

We are also pleased to offer volume discounts. For more details, please contact us.

#  Important Note for Existing Teams

If a team currently in either tier already has devices (or has had devices in the past), any additions or removals of devices will be billed according to the previous pricing structure. For teams without any prior device history, the addition of devices will be billed at the new rates.

With the recent introduction of the Device audit log, we've now updated the Device Agent to start logging events from the Node-RED instance running on your device.

This brings closer parity with the logging you get from a hosted instance.

The audit log events include details of the flows being updated, nodes being added or removed from the palette and other changes to the configuration.

Update to Device Agent v2.2 to start receiving the events.

Hot on the heals of our recent onboarding improvements and streamlining, we have now introduced a new, simpler and faster way of getting your devices configured and connected to the FlowFuse platform.

Now, when you create a device on the platform, you will be offered a simple "Setup command". Run this command in a terminal and the let the Device Agent do all the hard work for you.

To learn more about this, head to the FlowFuse Device Agent documentation.

This week has seen the release of the first major version of Node-RED Dashboard 2.0, with it, we've made available a new FlowFuse-exclusive feature, personalised multi-user dashboards.

This new feature will allow you to build applications that provide unique data to each user, build admin-only views, and track user activity, to name but a few. We're really excited to see what the Node-RED Community and our FlowFuse customers can do with such a powerful and flexible framework.

Back in June 2023 we announced that FlowFuse would be investing into building out the next generation of Node-RED Dashboard, the most popular UI framework for Node-RED.

We followed this up with the first release (0.0.1) in July, just one month later, and today, we are pleased to announce that we have reached a major milestone in this journey, with the release of our first major version (1.0.0) of Node-RED Dashboard 2.0.

To start editing flows on a device, it needs to be assigned to an application in your team. Up until now this has been a two step process; creating the device and then assigning it. This wasn't as intuitive as it needed to be.

To help streamline the user experience, you can now assign a device to an application when you create it. It's a small update, but it helps users get to where they want to be much quicker.

We have added some new blueprints to FlowFuse Cloud to help users get started with a range of common manufacturing scenarios.

They are available to all users on FlowFuse Cloud. Additionally, upon request, all our Teams and Enterprise Self-Hosted customers gain access to this collection.

List of new Blueprints:

• Andon Live
• CRUD for Mongo DB
• 5S Manufacturing checklist
• Performance Operator Terminal

Curious about what Blueprints are? Read our recent blog post that introduced Blueprints to FlowFuse.

For an overview of all available Blueprints check out our Blueprint Library.

The v2.0 release of the FlowFuse Helm Chart includes a breaking change for deployments making use of the forge.localPostgresql setting when upgrading. This is where the helm chart installs a dedicated PostgreSQL database instance.

With v2.0 we have updated the version of the Bitnami PostgreSQL Helm sub-chart we bundle and the upgrade process will require some manual intervention to ensure things work correctly. A fresh install should not require any extra steps.

The steps are documented on the Upgrade instructions page, please read them carefully before upgrading

Also included in this release is the ability to set resource constraints and Pod Security Context on the FlowFuse application, File-Server Application and MQTT broker containers if required. Details of how to set those can be found in the Helm Chart README.md

Four weeks ago, we launched the Device Groups feature, for our Enterprise customers. This innovation marked a significant step in simplifying device management within DevOps Pipelines. Now we enhacent the Device Groups functionality.

With this update, the behavior of Device Groups has been refined to further streamline your workflow. Now, whenever a Snapshot is assigned to a Device Group, any newly added devices to that group will automatically receive the update. This ensures that all devices within the group are consistently synchronized with the latest changes, eliminating the need for manual updates. This improvement not only saves time but also enhances the consistency and reliability of device management across your fleet.

The introduction of the Device Auditlog brings an enhanced level of monitoring and tracking for device-related activities, available to all FlowFuse users.

Events Recorded in the Device Auditlog:

• Fleet mode / Developer mode enabled/disabled
• Remote access enabled/disabled
• Credentials re-generated
• Device assigned

For organisations using Single Sign-On with FlowFuse, we have now added the ability to manage their user's team memberships and roles via their Identity Provider.

This makes it easier to control access to the FlowFuse Platform from providers such as Okta and Microsoft Entra. For example, you can create a group of Team Owners and a separate group of Team Viewers.

Whenever a user logs in via SSO, the platform will update their roles to match the groups they are in.

More information on configuring groups can be found in our Single Sign-on documentation.

This feature is available to Enterprise Tier teams on FlowFuse Cloud, as well as self-hosted Enterprise instances.

As part of our dedication to providing a secure platform for our customers, we operate a Bug Bounty programme to encourage responsible disclosure of potential issues.

With all disclosures we evaluate their severity in terms of their direct impact, the nature of the issue and overall risk.

We have received a number of reports recently that we have been evaluating. Whilst none of the recent disclosures has been deemed high severity, we have applied a number of updates to the platform.

These include:

• Tougher rate limiting on routes that manage user information including email addresses
• Better handling of the password-reset flow to prevent stale links being reused
• Avoiding disclosure of a user's email address to other members of a team

This last item is one I wanted to say a bit more about. As you would expect, a user's email address is sensitive information that we do not disclose to unauthorised users. However, we also consider a Team as having a higher level of trust between its members. On review, we have decided there is not a technical reason for this higher level of trust to include a member's email address, so we have removed it from the relevant API responses.

We value the effort people put into making responsible disclosures to us and look to reward the work where it meets our criteria.

Find out more about our Bug Bounty programme.

In our continuous effort to enhance user experience and clarity, we are pleased to announce an update to our device mode terminology. Previously known as "Default Device" mode, we have now rebranded it as "Fleet Mode." This change aims to establish a clearer distinction from "Developer Mode," thereby streamlining the understanding of operational modes for our devices.

• Fleet Mode: Runs any target Snapshots defined. Blocks remote editing of device.
• Developer Mode: Blocks any new Target Snapshots running, but allows for remote editing on the Device.

We are pleased to announce the introduction of Device Groups for Enterprise Tier customers. This new feature enables users to logically group their devices assigned to an application. Additionally, Device Groups can be integrated into the DevOps Pipeline. This integration facilitates more streamlined and efficient deployments across your fleet of devices.

The newly introduced feature offers email notifications tied to particular Audit log events, available to all users with Team Tier access or higher. This feature is designed to facilitate immediate notification and action in response to Node-RED Instance crashes. For detailed information and guidance on this functionality, please refer to our documentation.