Code export · Retool
Self-hosting Retool is not the same as owning the code
Export policy checked on September 2026
What comes out
What Retool actually exports.
Retool is where the words matter most, because "self-hosted" and "exported" get read as "I own the code" — and neither means that. Here's what actually comes out, precisely.
App config — JSON or Toolscript
Export an app as a single JSON file or a Toolscript ZIP of many files, including its queries and configuration, and re-import it elsewhere in Retool.
Source Control (Git)
Sync app definitions to a Git repo to manage them "as code" — versioned config, still bound to Retool.
Self-hosting
Run Retool's platform on your own infrastructure (single-tenant, Docker or Kubernetes + Helm, or Retool-managed on your AWS).
Not a standalone app
None of the above is a React/Node project you can compile and host without Retool — they all need Retool's runtime.
How the export works: From an app's actions menu, Export to JSON or Toolscript ZIP; connect Source Control to push definitions to Git; or deploy a self-hosted instance for data residency. Every one of these keeps Retool in the loop.
The gap
What the export does not include.
The gap here isn't a missing feature — it's that the thing people assume they're getting (owned source) doesn't exist. What Retool gives you is control over deployment and config, not a codebase you could take to a different platform.
There's no standalone source code
The JSON/Toolscript is a Retool app definition — a config DSL that only runs inside Retool's engine. Open it and you'll find your app described, not a program you can compile. Without Retool, it's inert.
BlockerSources: [1]Self-hosting is not owning the code
Self-hosting gives you infrastructure control and data residency — Retool running on your servers. It's still Retool, positioned for regulated and enterprise needs, and it doesn't hand you source you could rebuild from. "On our infra" and "our code" are different claims.
MajorSources: [2]Not everything even syncs
Source Control manages app definitions, but Query Library queries aren't synced by it — so even the "as code" story has holes if you're treating Git as your full source of truth.
MinorSources: [1]
The real question
Is the exported code maintainable?
Retool export:Mixed
As a way to run Retool, it's genuinely strong: Git-backed config, promotable environments, and self-hosting for data residency make Retool maintainable as a platform. As an exit, it's weak, because there's no owned codebase at the end of it — the exported JSON/Toolscript is inert without Retool's runtime, so leaving means rebuilding the tool, not migrating a project. If you need an internal tool you can host and version, Retool is fine; if you need software you own independently of Retool, the export won't get you there.
Your options
What to do with the export.
Three honest routes. The right one depends on how far the app has to go and who is going to own the code once it gets there.
- 01
Keep building on Retool
Use Source Control and environments to manage your Retool apps as versioned config. It's a solid internal-tooling setup.
- Right when the tool is internal and staying on Retool is acceptable long-term.
- Wrong when you need software you own independently of Retool's runtime.
- 02
Self-host for control, not ownership
Deploy Retool on your own infrastructure for data residency and compliance — knowing it's still Retool, not your code.
- Right when your constraint is where data lives, not who owns the source.
- 03
Rebuild as owned code
Re-implement the tool as a real application you own, using the Retool app as the working spec and carrying your data across.
- Right when the tool is going customer-facing or you need to own and extend it beyond what Retool allows.
Self-hosting vs owning the code — the difference Retool's marketing blurs
These get treated as the same thing and they aren't, so here they are side by side. Self-hosting Retool: Retool's platform runs on your infrastructure; you control where data lives; you still need Retool to run your apps; you can't compile or rebuild from what's on your servers. Owning the code: a standard codebase (React/Node, say) you can open, host anywhere, hand to any developer, and run with no dependency on the original vendor. Retool's JSON/Toolscript export and self-hosting deliver the first. If what you actually need is the second, the honest route is a rebuild.
- Config export
- JSON / Toolscript
- Runs without Retool
- No
- Self-host
- Still Retool
- Own source
- No
FAQ
Questions people actually ask.
- Can you export Retool app source code?
- No — not as standalone source. You can export an app's configuration as JSON or a Toolscript ZIP, and sync it to Git via Source Control, but that's a Retool app definition, not a compilable codebase. It describes your app for Retool to run; it isn't a program you can host on its own.
- Is self-hosting Retool the same as owning the code?
- No. Self-hosting runs Retool's platform on your own infrastructure for control and data residency — it's still Retool, not your source. You gain where data lives and how it's deployed; you don't gain a codebase you could take elsewhere or rebuild from. They're different things that sound alike.
- What format do Retool apps export in?
- Either a single JSON file or a Toolscript ZIP of many files, including the app's queries and configuration, re-importable into Retool via "Create new → From JSON." Source Control can also sync these definitions to a Git repo so you can manage them as versioned config.
- Does the exported JSON run without Retool?
- No. The JSON/Toolscript is a config DSL that only executes inside Retool's engine — self-hosted or cloud. On its own it's inert: there's no runtime in it. That's why leaving Retool is a rebuild rather than a lift-and-shift of the exported files.
Every builder, one table
Code export across the hub, at a glance.
The same status table on every export page. “Exports” means real, usable source comes out; “partial” means a major layer is missing; “none” means no source export at all. The nuance is on each page.
| Platform | Code export | What you get |
|---|---|---|
| Lovable | Exports code | React repo via GitHub |
| Base44 | Partial export | Front end; backend locked |
| Webflow | Partial export | Front end only, no CMS |
| FlutterFlow | Exports code | Dart / Flutter source |
| Framer | No code export | Host-only, no export |
| Bolt.new | Exports code | Project files / GitHub |
| Bubble | No code export | No source export |
| Replit | Exports code | Full code, you own it |
| Softr | No code export | No code (data only) |
| Glide | No code export | No code (data only) |
| Adalo | No code export | No source export |
| RetoolThis page | Partial export | Self-host, not source |
| Xano | Partial export | API portable, no export |
Sources
Every claim, traced to a primary source.
The numbered references in the body link here. We cite vendor docs, pricing pages, changelogs and named reporting — dated where the document is dated, so the page can be re-audited each quarter.
- [01]Import and export apps — JSON and Toolscript
Retool Docsdocs.retool.com
- [02]Self-hosted deployments — single-tenant, Docker/Kubernetes
Retool Docsdocs.retool.com
Own the Retool app outright?
We’ll map the route to code you actually own.
Book a call with Jackson, our Growth Partner — he’ll walk your export or app, the gaps that matter, and a fixed-price plan to get it production-ready, live on your screen. Or get an instant estimate first.
Or see fixed-price migration packages and how we work.