Can you export a workflow as a standalone app?

The short answer: usually no. A workflow platform's native export is the workflow definition - a JSON or proprietary file - not a program. The export is genuinely useful to someone who runs the same platform; it is not something a client can double-click. To deliver an automation that runs with no platform at all, you either accept one of the workarounds below (each with a real cost), or the automation is built as a compiled desktop artifact in the first place - which is the model this directory exists for.

Export features differ per platform and change over time; each vendor's own documentation is authoritative for what it ships today. This page compares the delivery models, which are stable, rather than any vendor's current feature list.

What 'export' gives you today

Definition export (JSON or similar) - the universal baseline. It round-trips between instances of the same platform and nothing else.
Code export or generation - where offered, it produces source tied to the platform's runtime or libraries, which still needs an environment to execute in.
Template and marketplace sharing - distribution inside the platform's ecosystem, not outside it.

None of the three is a standalone app: each one presumes the recipient installs, licences and connects to the same platform you used.

The workarounds, and what each really costs

Option	What it takes	The hidden cost
Share the JSON export	Recipient installs the same platform and imports it	A subscription per recipient; support questions about their instance
Self-host the platform for the client	A server per client (or shared multi-tenancy), upgrades, backups	You become a hosting provider; the ops bill is recurring
Re-implement in a scripting language	Real engineering: rewrite, test, package, maintain	Two codebases forever - the workflow and the rewrite drift apart
Negotiate an embedded/OEM licence	A commercial agreement with the platform vendor	Annual terms and branding constraints - see the embedded licence comparison
Build it as a compiled artifact	Author the workflow once in a product that compiles standalone launchers	A one-time builder licence; no per-client hosting, no agreement

How the compiled desktop artifact model works

In the model this directory distributes, a workflow is compiled into a launcher executable named after its bot. At launch the executable fetches its published configuration from the directory by the id carried in its own filename - which is why every listing insists the downloaded file must never be renamed - then runs locally and writes its output beside itself. Nothing is queued on a server and no platform account exists on the customer's side.

Updates travel through the same configuration channel: on a live-channel bot, a delivered launcher picks up the newest published configuration at its next start, within the cache window the security page documents. The site FAQ covers the filename rule, offline behaviour and verification steps in full.

JSON export vs code export vs compiled launcher

Dimension	JSON export	Code export	Compiled launcher
Recipient must install	The same platform	A runtime plus the platform's libraries	Nothing
Platform licence needed	Yes, per recipient	Usually yes	No
Hosting	Platform cloud or self-hosted	Yours	The customer's own machine
Branding surface	The platform's	Yours, with effort	Yours on the artifact and listing
Update path	Re-share the file	Re-deploy the code	Configuration channel; no re-delivery on the live channel
Recipient can edit it	Fully	Fully	Only the inputs you expose; the definition follows your encoding choice

Frequently asked questions

Can I convert a workflow to an exe?

Not by converting the file: a workflow export is a definition in the platform's own format, and no general converter turns one into a trustworthy executable. The practical route is to rebuild the automation in a product that compiles to a standalone launcher - the desktop product behind this directory does exactly that, producing a named executable per bot.

Does exporting a workflow include my credentials?

It should not, and here it never does: secrets are acquired at run time or held in configuration the launcher fetches at launch, never embedded in the distributed artifact. The Input tab of every listing shows exactly which values are prompted per run.

Can the recipient edit the automation they receive?

That is your publishing choice. A plain-encoded configuration is readable by anyone who knows the bot's id - the security page documents this trade-off in full - while an encrypted-string configuration keeps the workflow definition unreadable without the password.

Do updates require re-delivering the executable?

No, on the live update channel: the launcher fetches the newest published configuration at its next start, so selector repairs and logic updates arrive without a new download. Pinned listings are the deliberate exception - each version keeps its own launcher id.

Can exported workflows run without the vendor's cloud?

Only where the platform offers a self-hosted edition, and then the hosting, upgrades and operations burden is yours for every client. That cost is the reason people look for standalone artifacts in the first place; the workaround table above compares it honestly.

Sell bots you build Download the desktop product Read the documentation

Next comparison: embedded licence alternatives, or back to the comparison index.