Edit the flow together. Deploy it as one version.

Everyone who opens the editor works on one shared draft that lives on the connector. A change reaches every open editor within about a tenth of a second, and the running flow changes only when someone deploys.

Read the docs

The flow editor with two people in it. Ann has the Flag over limit node open in the side panel. A red ring with the name Bob and his cursor mark the Only running machines node he has selected. Light theme.The flow editor with two people in it. Ann has the Flag over limit node open in the side panel. A red ring with the name Bob and his cursor mark the Only running machines node he has selected. Dark theme.
The flow editor with two people in it. Ann has the Flag over limit node open in the side panel. A red ring with the name Bob and his cursor mark the Only running machines node he has selected. Light theme.The flow editor with two people in it. Ann has the Flag over limit node open in the side panel. A red ring with the name Bob and his cursor mark the Only running machines node he has selected. Dark theme.
Ann's screen. Bob has the Only running machines node selected, so it carries his colour and name, and his cursor is on the canvas. Two named tokens on a demo flow.

One draft, and you can see who is in it.

Who is here
Avatars in the top bar list everyone in the editor, named from the OIDC sign-in or the API token. Each shows what that person is doing, and Follow mirrors their flow and viewport until you pan or zoom.
Where they are
Cursors are drawn on the canvas. A node someone has selected or opened gets a ring in their colour with their name, and the side panel says the person is editing this node while they work in its form.
What is unsaved
The Draft chip next to Deploy counts the changes against the running flow and names who wrote them.
The Shared draft popover. It counts the unsaved changes and lists Ann and Bob under Changed by, recorded as co-authors, with a Discard draft changes button. Light theme.The Shared draft popover. It counts the unsaved changes and lists Ann and Bob under Changed by, recorded as co-authors, with a Discard draft changes button. Dark theme.
The Draft chip opens a list of the unsaved changes and who made them. Those names become the co-authors of the next version.

A deploy is one version, with its co-authors.

The version history stays the record of what ran. It now also says who wrote it.

The Deploy dialog. Two changes go live, the shared draft is deployed with everybody's edits, Bob is named as co-author of the version, and a deploy message is filled in. Light theme.The Deploy dialog. Two changes go live, the shared draft is deployed with everybody's edits, Bob is named as co-author of the version, and a deploy message is filled in. Dark theme.
The Deploy dialog names the co-author before you confirm.
The History panel. The newest version is marked live, shows its deploy message, and names Ann and Bob as the people behind it. Light theme.The History panel. The newest version is marked live, shows its deploy message, and names Ann and Bob as the people behind it. Dark theme.
History shows the actor first, then the co-authors.
Deploy
Takes the shared draft as it is now and creates one version. The person who deployed is the actor. Everyone else who changed the draft since the previous version is a co-author, shown in History. Every open editor is told which version went live and who deployed it.
Refused when there is nothing to deploy
A deploy is refused when the draft equals the live flow, and when the live version is not the one the caller expected.
Discard draft changes
Resets the draft to the running flow for everyone, after a confirmation. Changes still queued on offline machines are void, and those editors are told.
A deploy by another route
An API call, MCP, a rollback, a promotion or an import is announced to every editor too. The draft is kept, the unsaved count is taken against the new live flow, and the list of authors starts again.

Viewers watch. Protected environments stay read-only.

  • Deploy and discard need the editor role and are audited as flow.deploy and flow.discard.
  • Viewers and operators watch live but cannot edit. The server refuses their changes whatever the browser sends.
  • A protected environment is read-only for everyone, and presence still works. Its draft follows the live flow after every promotion or rollback.

How changes merge, field by field.

The server holds the draft as nodes, edges and flows, puts every change in order, and sends the same order to every client. The rules are deterministic.

Different fields of one node
Both changes survive, whoever sent first. A node’s position, label and script are separate fields.
The same field
The change the server saw last wins.
A delete and an edit
The delete wins. A concurrent move or edit of that node finds no target and is dropped. Adding the same id again brings the node back.
A wire that cannot exist
A wire to a node that was just deleted is dropped. A wire that would make a cycle, duplicate one or cross flows is refused, as is deleting the last flow. The client that sent it is told and resynchronised.
Undo
Takes back your own edits. Other people’s changes made since are kept.
Where this falls short

Text merges per field, not per character. If two people type into the same script at the same moment, the later change replaces the earlier one. We chose this over a character-level CRDT such as Yjs because the draft is a small graph of JSON fields that one server already puts in order: no tombstones, no binary document format, no extra dependency.

Offline, then back.

  • The editor reconnects with backoff. While offline the top bar shows how many changes are queued, and your edits stay on the canvas.
  • On reconnect it sends the last change it applied. The server answers with what was missed, or with the whole draft after a connector restart or more than 4,096 changes. Queued changes are replayed on top, and a change the server already applied is ignored.
  • If the draft was discarded while you were offline, your queued changes are dropped and you are told. Closing a tab with unconfirmed changes asks first.
  • The draft file is written 150 ms after the last change and at shutdown, so it survives a restart. Back it up with the rest of the data directory.

Questions about editing together.

Something missing? Write to marketing@opexcg.com.

Can two people edit the same script at the same time?

They can, and the later change wins. Text is merged per field, not per character, so a script typed into by two people at once keeps the last version the server saw. Edits to different fields of a node, such as one person moving it and another renaming it, both survive.

Does editing change the running flow?

No. Everyone edits a shared draft. The running flow and the version history change only when an editor deploys, and that deploy records everyone who changed the draft as co-author.

What can a viewer see in a shared session?

Viewers and operators watch changes arrive live and show up in the avatar list, but they cannot edit. A protected environment is read-only for everyone, and presence still works there.

From download to first record in minutes.

Run one binary, connect a PLC, a CNC or a webhook, and watch the records arrive in the editor.

Builds for Linux (x86_64 and ARM64), Windows and macOS.

  • One binary
  • Raspberry Pi to rack server
  • Signed delivery with retries

Sizing questions or an air-gapped install? Email marketing@opexcg.com or read the quick start.