The busywork between your apps, done by itself. You decide what goes live.
Let Keel, GoRunner’s assistant, draft the automation, or build it yourself. It runs the same way, every time.
Draft it. Test it. Switch it on.
“When someone fills in my form, add them to my sheet and email them.”
A short silent film of the GoRunner app, using example data. It opens in Keel, where someone has asked “When someone fills in my form, add them to my sheet and email them.” Keel works through it (about 45 seconds, sped up in the film) and drafts a workflow called New signup welcome: a form trigger, a Google Sheets step that adds a row, and a Gmail step that sends a welcome email. They apply the draft and open it in the builder, press Test; Keel’s panel gives way to the Runs feed, and each step reports that it worked and how long it took; the run passes in 1.5 seconds. They press Publish and the workflow is live. On the Runs page, sped up over a morning, new runs of New signup welcome arrive on their own and fold into one line, all worked.
Busywork you can hand over today.
“New meeting? Make a notes doc and email the link.”
An example. Meeting notes: when a meeting is booked in Google Calendar, it makes a notes document in Google Docs and emails the link with Gmail. It worked in 1.9 seconds, and new runs keep arriving on their own.
An example.Durations are example values.
Works with your apps.
When it matters, it asks first.
It emails a person, then waits, even for days.
An example. In GoRunner’s Runs list, a run of the workflow Expense approvals arrives and is held for an approval. The approval email arrives in a mail inbox. Press Approve or Reject in the email, then confirm on GoRunner’s decision page, which needs no sign-in. The run then continues: on Approve it logs the expense to Google Sheets, on Reject it emails Sam.
An example.The approver needs no GoRunner sign-in.
Your coding assistant can build here too.
Its token can draft and test. Going live stays with you, unless you give it Publish.
A recorded session, condensed. A person makes a token in GoRunner’s New token dialog with Read, Write and Run for workflows, Read for connections and Read for runs; Publish is left unticked. Claude Code, holding that token, searches GoRunner’s pieces, validates and creates the workflow Order approval on webhook, which appears in the Workflows list as a draft. It then tries to publish and is refused: it requires the workflow:publish scope. It runs a test of the draft instead, which is held for an approval. Publishing stays in the app, with the person: the draft’s Publish button in the builder.
claude mcp add gorunner --transport http https://api.gorunner.io/mcp/build --header "Authorization: Bearer grt_…"Faster than a blink.
A blink takes 100 to 400 ms. GoRunner’s own work on a run: 3.66 ms, the median. 27 fit in the fastest blink.
Median at 800 requests a second: a webhook and one built-in step, no outside app, answered when the run finishes; the app on 2 vCPUs, the caller on the same machine. The apps a workflow calls, like Google, add their own time. Measured by the GoRunner team on 22 Sep 2026. A blink: 100–400 ms (BioNumbers 100706). How we measured
Each green block is one run answered: 3.66 ms.Slowed down 20×
Same two vCPUs. Nearly twelve times the calls.
Each one ran alone on the same 2 vCPUs and 4 GiB, its database on 4 more, with 64 connections calling one tiny workflow. Every second, GoRunner answered 1,232 calls, Activepieces 105 and n8n 53.
Each green square is one call answered with the correct reply. CPU a call counts the app and its database.One second, slowed down 10×
Measured by the GoRunner team on one machine, not independently · GoRunner in dev mode with its webhook limit lifted.
How this was measured
Calls answered a second with 64 connections kept busy: correct replies in the last 2 of 4 minutes on a fresh stack, on 24 Sep 2026. GoRunner’s and n8n’s figures are the median of three sessions; Activepieces’ are from one. The drawing plays one such second at an even pace, slowed down 10×.
Each product’s app shared a limit of 2 vCPUs and 4 GiB. Postgres and Redis ran outside it, on 4 other vCPUs set up the same for all three; GoRunner drew about 1.1 of them, so CPU a call counts app and database together.
A tiny flow: a webhook, one built-in step that sets two fields, a JSON reply, every run stored in Postgres. No outside services, so this measures each engine’s own overhead, not a real workflow.
One machine, not a server: an Apple M4 Pro with Docker Desktop, the load generator running on it too. Read the numbers side by side, not as absolutes.
GoRunner (commit 5fbf8f54) ran in dev mode with sign-in off and its per-address webhook limit lifted, since all calls came from one address. n8n 2.40.5 ran in queue mode, not its default; its default single process had the same capacity. Activepieces 0.91.1 ran on its shipped defaults, the best of four shapes its docs describe. Its docs size this shape at about 3.5 vCPUs and 6 GB, more than this limit; here it peaked at 3.5 GiB.
GoRunner was not at full load with 64 connections: 1,232 is a floor, not its limit. The other limits are on the method page. How we measured
A third of the weight.
Container image size: GoRunner 87.3 MB, n8n 266.1 MB, Activepieces 411.5 MB. Less to download, update and store.
One container drawn = 10 MB. Compressed images, linux/arm64, measured 22 Sep 2026: GoRunner commit 5fbf8f54, n8n 2.40.5, Activepieces 0.91.1. Not counted: the databases beside them. GoRunner needs Postgres and Redis; n8n can run alone on its built-in SQLite; Activepieces uses Postgres and Redis in production. Size, not speed.
Our cloud, or your servers. Self-hosting by license, on request.