If it only runs while a tab is open, it is not automation

If it only runs while a tab is open, it is not automation. It is a script you are babysitting.

A category of automation tool runs entirely in your browser. It is genuinely appealing: nothing to sign up for, your data never leaves the machine, and you can build something useful in ten minutes. We shipped a browser-first version of Zymura before doing anything server-side, so this is not a criticism from the outside.

But there is a hard limit, and it is worth naming plainly.

The limit

A browser tab is not a runtime you control. Close it and execution stops. Beyond that, several things happen even when you leave it open:

• Background throttling. Browsers aggressively throttle timers in inactive tabs. A setInterval of one minute becomes one minute in the foreground and something much longer in the background.
• Sleep. Close the laptop lid and nothing runs, tab open or not.
• Tab discarding. Under memory pressure, browsers unload background tabs entirely and reload them when you return.
• The obvious one. Your machine has to be on.

Time you spend, and how reliably it happens

What this means in practice

Browser execution is excellent for things you trigger. Click a button, transform some data, get a result. That is a real use case and it is genuinely private, because nothing leaves the device.

It falls apart for anything on a schedule, which is most of what people mean by automation. "Every morning at eight" and "while a tab happens to be open" are not compatible requirements.

The trade you actually make

Server-side execution is not free. It requires exactly the thing browser-only tools avoid: your credentials have to be stored somewhere the server can read them, because a server cannot authenticate to Slack on your behalf without them. That is arithmetic, not a design choice, and anyone telling you otherwise is being imprecise.

So the honest framing is not "browser-only is bad". It is that you are choosing between two real costs:

• Browser-only: nothing leaves your device, and nothing happens unless you are there.
• Server-side: it happens without you, and a third party stores a credential.

Which is right depends entirely on what the flow does. If it is moving data between two systems you already trust that provider with, the second cost is small. If it touches something highly sensitive and only needs to run when you are at the desk anyway, the first may be a better trade.

What matters is that the choice is made explicitly, and that whoever holds your credentials tells you where they live and what happens to them in run logs. On our side that is written out on the security page, including the parts that are not flattering.

The related question — what it costs to run scheduled work yourself instead — is covered in running a script on a schedule without a server.