Your automations should not need our servers

Most automation platforms are cloud products with a desktop client attached. Your workflow definition lives on their servers, runs on their workers, and touches your files through an agent you install. That model has real advantages. It also means an outage, a pricing change or a shutdown is your problem.

AutoFlowRPA is built the other way around. The engine that executes your workflows has no server dependency. Not "encrypted in transit". Not "we don't look at it". There is no call to make.

What that actually means

When you press Run, a local Python process reads your workflow and executes it on your machine. It opens your spreadsheets, drives your browser, calls the APIs you configured. The workflow file is on your disk. The run log is on your disk. Nothing is uploaded, because there is nowhere to upload it to.

This is enforced, not just promised: no code in the engine may add a server call, upload or telemetry path. It is a rule the project holds itself to, and it is the reason the engine can be audited by reading one directory.

Practical consequences:

• Works offline. On a plane, behind an air gap, on a locked-down corporate network — the workflow does not care.
• Your credentials stay yours. API keys and OAuth secrets are stored locally and encrypted at rest with AES-GCM. They are sent to the provider they belong to and nowhere else.
• No per-run pricing, no queue. Your laptop is the worker. Run it a thousand times at three in the morning; nobody is metering it.
• Regulated data stays put. If your compliance rule is "this file must not leave the building", a local engine is not a workaround — it is the answer.

Where we are honest about the limits

Local-first is a real trade-off, not a free win.

Licensing does talk to a server. Sign-in, the 30-day trial and subscription checks go through our backend. That is deliberate and we are not going to pretend otherwise. What matters is the separation: licensing lives in the app shell, the execution engine stays offline. Once activated, running workflows needs no connection.

Your machine has to be on. There is no cloud worker to pick up a scheduled run while your laptop is shut. Scheduling works, but it works on a machine that is awake.

No shared execution history. A team does not get one dashboard of every run across every member, because those runs never leave the machines they ran on. For some teams that is the point; for others it is a real gap.

You maintain your own environment. Heavy optional tools — FFmpeg, Tesseract OCR, browser engines — install on demand from inside the app, which keeps the installer small. But they land on your machine, and updating them is yours.

Who this suits

Local-first fits you if your automations touch files and applications on your own computer, if your data is sensitive enough that "it never leaves" is worth something, or if you would rather not have a per-execution bill.

It fits less well if you need always-on unattended runs on infrastructure you do not maintain, or a single audit trail across a whole team. We would rather say that plainly than sell you something that does not fit.

Try it

The app is free to download and the 30-day trial starts when you sign in. It runs on Windows and, as of v0.1.22, on macOS.