Build it, test it, publish it, and watch every execution
What Latchyard does in its first release, from the canvas to the audit log. Every feature on this page is in self-hosted Latchyard and in Cloud.
Build
Draw the workflow on a canvas, keep state inside Latchyard, and write code where a node doesn't fit.
- The canvas Copy nodes from one Latchyard instance and paste them into another. Moving a node changes the layout, never the workflow's logic. Sticky notes add explanations beside the nodes.
- The assistant The in-editor assistant proposes a change to your draft as a diff. You apply it and can undo it, and it acts with your own permissions.
- Data tables A project's tables have typed columns that workflows read and write. A write commits exactly once, together with the node run that makes it.
- Writable variables A Set variable node writes a counter or a marker, with compare-and-set and atomic increment. No expression or code node can write one.
- Code nodes JavaScript, TypeScript and Python, with an allow-list of packages that includes pandas and numpy. Code nodes run in a separate sandboxed process.
- Folders, tags and search Folders and tags for workflows, and ⌘K search across workflows, credentials and execution IDs.
Test
Run part of a workflow against saved data before anything reaches production.
- Test runs with pinned data Pin a node's output and test runs use it instead of calling the service again. Production executions ignore pinned data.
- "Test this node" and "Test up to here" A test run can stop after the node you choose. Upstream nodes use pinned data, else your latest test output when their input is unchanged, else they run.
- Listen for test event A trigger's test URL accepts real events for up to 10 minutes and shows them in the editor.
- Test in the environment you pick A test run uses the credentials of the environment chosen in the editor. Pinned data is how a test avoids side effects.
Ship
Publish a version to an environment, promote the exact version you tested, and roll back in one step.
- Environments Add environments such as development, staging and production. Each one has its own credential, variable and secret values, webhook URLs and schedules.
- Promotion without copies Promoting makes an existing version active in another environment. What ran in staging and what runs in production have the same content hash.
- Publishing checks first Publishing swaps the active version in one transaction. It refuses a version whose credential has no value in the target environment, and names the missing one.
- Protected environments Only project admins publish to a protected environment. It can also require a second admin to approve each publish request.
- Version history Version history shows the versions you published, with a diff between any two and a rollback that republishes an earlier one. Unpublish and delete are separate actions.
Run
See where every execution stands, and fix the ones that stopped without starting again from the top.
- Progress saved after every node run Each node run commits on its own. After a crash the execution continues from the last committed node run, and nothing that finished runs again.
- Retries continue, they don't restart Retrying a failed execution keeps the node runs that succeeded and restarts only the ones that failed, on the same version.
- Execution list Filter by status, workflow, trigger and time. Cancel, retry in bulk and delete in bulk.
- Stuck node runs When a node run's outcome is unknown, an editor marks it succeeded, retries it anyway or fails the execution. Each choice is audited with a reason.
- What to keep Each workflow keeps all production execution data, failures only, or none.
- Notifications and phones Notifications arrive in the app and by email. Execution status and approval pages work on a phone. The editor is built for desktop.
AI and agents
Agents run on the same durable engine as every other node, so a crash never repeats a decided action or pays again for a model call it already saved.
- Agent nodes An agent node has ports for a model, memory, tools, an output parser and guardrails. Any node operation, sub-workflow, OpenAPI operation, other agent or MCP tool can be a tool. MCP, the Model Context Protocol, is the open standard AI agents use to reach tools on other servers.
- Every step saved Each model call and tool call is saved as its own step. A new attempt continues from the saved steps and repeats only the one in flight.
- Approvals inside the loop A tool can require an approval before it runs. The approver approves, edits the arguments or denies, and the agent continues from there.
- Spend budgets Every model call reserves its cost before it runs. Budgets cap tokens, cost and time per agent node, workflow, execution or chat session.
- Checks on what an agent reads and sends Guardrails check an agent's input, tool calls and output for personal data, secrets and URLs. Publishing flags an agent that combines private data, untrusted input and a way to send data out.
- MCP servers, in and out The MCP client node fixes each tool's schema when you publish, and fails the call if the server changes it. External agents use the built-in MCP server, and its tokens can't run, edit or publish workflows unless you grant that.
Security
Each organisation's code runs in its own sandbox, and its content is encrypted under its own key.
Report a vulnerability- Sandboxed runners per organisation User code runs in a separate runner process with no network sockets. A runner serves one organisation and is never reused for another. On shared Cloud each runner has its own gVisor sandbox.
- Encrypted under the organisation's key Credentials, execution data, data-table rows, drafts and the audit log are encrypted with AES-256-GCM under the organisation's own key. A database dump without the root key yields only metadata.
- Secrets stay on the server A secret is write-only once saved, never sent to the browser, and scrubbed from outputs and logs. By default, code sees a placeholder and the egress proxy adds the credential on the way out.
- Audit log Each organisation has an append-only, hash-chained audit log of what people, service accounts and tokens did, including every use of a secret.
- Erasure by key Deleting an organisation ends by destroying its encryption keys. Copies of its data become unreadable once the backups that hold those keys expire.
Get notified when the first release ships
Leave your address and we email you when the first release is out.