MeshHook now runs your workflows on c0mpute
MeshHook now runs your workflows on c0mpute
MeshHook is our MIT-licensed, webhook-first workflow engine: you drag nodes onto a canvas, wire them up, and a webhook starts a run. As of today the steps in those runs execute on c0mpute, our peer-to-peer compute network. Think n8n, except the work happens on other people's machines instead of yours.
Try it at meshhook.com.
What runs where
- AI steps call open models on c0mpute nodes through the Infernet open market. They are peer-only: a step never falls back to a paid hosted model. The default is qwen2.5:1.5b, then 0.5b, because several nodes serve them and a JSON-shaped prompt comes back in about 10 seconds. You can pick a bigger model per node if you can wait for it.
- JMESPath transforms and HTTP calls are auctioned as workflow.step jobs. Any c0mpute worker on 0.2.56 or later bids on them by default. The winner runs the step and returns a result MeshHook checks by hash.
- Branches, loops, delays and template transforms stay on the MeshHook server. They are cheap, and they need the run's state.
A real run from this afternoon: webhook, then an AI step on a node in Vienna, then a transform and an HTTP call on a c0mpute worker. 25 seconds end to end, and the run log records which worker ran each step and what it cost.
Your credentials stay home
A worker sees the whole step it runs, so MeshHook keeps an HTTP call on its own server whenever it carries anything secret: an Authorization or cookie header, anything that looks like a key or token, user:pass@ in the URL, or a secret template. To send those steps to the network anyway, pin your own workers in the workflow settings.
Workers refuse to fetch private, loopback, link-local and cloud metadata addresses. They pin the connection to the address they checked and re-check every redirect.
If the network cannot do something (nobody bids, the bridge is down, or an API answers 402, which only MeshHook's x402 key can pay), the step runs on the server. The log says why.
Pick per workflow
The editor has a Runs on menu with four options: Auto, c0mpute network, This server, or Private. Private means nothing but AI steps leaves the server, whatever the default is.
Run a worker
Every c0mpute worker on 0.2.56 or later serves workflow steps. Install one with:
curl -fsSL https://c0mpute.com/install.sh | sh
Every node you add makes everyone's workflows faster. The protocol details are in DIP 0030, in the c0mpute repo.
Source: profullstack/meshhook and profullstack/c0mpute.
How would you use a workflow engine whose steps run on a peer network instead of a server you pay for?
Mentions
MeshHook now runs your workflows on c0mpute MeshHook now runs your workflows on c0mpute MeshHook is our MIT-licensed, webhook-first workflow engine: you drag nodes onto a canvas, wire them up, and a webhook starts a run. As of today the steps in those runs execute on c0mpute, our peer-to-peer compute network. Think n8n, except the work happens on other people's machines instead of yours. Try it at meshhook.com. What runs where - AI steps call open models on c0mpute nodes through the Infernet open market. They are peer-only: a step never falls back to a paid hosted model. The default is qwen2.5:1.5b, then 0.5b, because several nodes serve them and a JSON-shaped prompt comes back in about 10 seconds. You can pick a bigger model per node if you can wait for it. - JMESPath transforms and HTTP calls are auctioned as workflow.step jobs. Any c0mpute worker on 0.2.56 or later bids on them by default. The winner runs the step and returns a result MeshHook checks by hash. - Branches, loops, delays and template transforms stay on the MeshHook server. They are cheap, and they need the run's state. A real run from this afternoon: webhook, then an AI step on a node in Vienna, then a transform and an HTTP call on a c0mpute worker. 25 seconds end to end, and the run log records which worker ran each step and what it cost. Your credentials stay home A worker sees the whole step it runs, so MeshHook keeps an HTTP call on its own server whenever it carries anything secret: an Authorization or cookie header, anything that looks like a key or token, user:pass@ in the URL, or a secret template. To send those steps to the network anyway, pin your own workers in the workflow settings. Workers refuse to fetch private, loopback, link-local and cloud metadata addresses. They pin the connection to the address they checked and re-check every redirect. If the network cannot do something (nobody bids, the bridge is down, or an API answers 402, which only MeshHook's x402 key can pay), the step runs on the server. The log says why. Pick per workflow The editor has a Runs on menu with four options: Auto, c0mpute network, This server, or Private. Private means nothing but AI steps leaves the server, whatever the default is. Run a worker Every c0mpute worker on 0.2.56 or later serves workflow steps. Install one with: curl -fsSL https://c0mpute.com/install.sh | sh Every node you add makes everyone's workflows faster. The protocol details are in DIP 0030, in the c0mpute repo. Source: profullstack/meshhook and profullstack/c0mpute. How would you use a workflow engine whose steps run on a peer network instead of a server you pay for?