TL;DR
Retool is a strong choice for panels over data your company already connects to it, and it now generates React apps from a prompt. If your own agent writes the tool as ordinary code in your repository, in whatever stack it chooses, floo is the alternative: it deploys that code from GitHub with sign-in, data, schedules, and agent keys, and the code stays yours.
- Where the app runs: Retool apps publish to Retool, and their server-side functions run on Retool's backend. floo runs the containers your repository defines.
- Stack: Retool's app import supports React with Node.js or Supabase backends. floo builds any service from a Dockerfile, with guides for Next.js, Rails, Django, FastAPI, and Express.
- Git: Retool's pricing page lists Source Control on Enterprise. On floo, GitHub is the source of every deploy.
- Where Retool leads: connectors to many databases and APIs, and SSO, role-based access, and audit logging that every app inherits.
Facts about Retool come from its own documentation and pricing page, read on October 29, 2026. Sources are listed at the end.
What changed at Retool?
Retool now has two kinds of app. New apps are generated as React code, by prompting Retool's agent or by building locally with Retool's CLI. Classic apps are the older canvas of predefined components on a 12-column grid. Retool's homepage speaks directly to people building with coding agents and offers its MCP server or CLI to build an app and deploy it on Retool.
So the question is no longer "code or no code." Both platforms host code an agent wrote. The difference is where that code lives, what it can be written in, and where it runs.
How do they compare?
| Retool | floo | |
|---|---|---|
| Who writes the app | Retool's agent, or your agent through Retool's CLI | Your agent, in your repository |
| Stack | Retool-native React; server logic as TypeScript functions on Retool's backend | Any service with a Dockerfile; guides for Next.js, Rails, Django, FastAPI, Express |
| Git | Pull requests through Source Control, listed on Enterprise; otherwise Retool's internal repository | Your GitHub repository, or a repository floo hosts |
| Sign-in | Your organization's login, SSO, role-based access, and audit logging, inherited by every app | Invite-only sign-in with a floo account, including Google; no app-user SAML or OIDC yet |
| Data | Your connected resources, Retool Database (Postgres), Retool Storage | Managed Postgres, Redis, and S3-compatible storage declared in floo.app.toml |
| Scheduled work | Retool Workflows, with cron syntax | [cron.<name>] in config, run in your app's container |
| People who only use the app | Billed per user per month, split into builders, internal users, and external users | No per-user price; you pay for usage |
| Environments | Staging and production resource environments on paid plans; published versions you can restore | Dev and prod, pull request previews with their own database branch, rollback by deploy |
Where does the code live?
With Retool's CLI, the code sits on your machine while you work. push sends changes to Retool and starts a preview build, and publish puts the app on a live URL. Retool's docs say that for an app without Source Control protection, the CLI works only with Retool's internal repository. Source Control, which manages changes through pull requests on GitHub, GitLab, and other hosts, is checked for Enterprise on the pricing page, as is self-hosting.
On floo, floo.app.toml in the repository defines the app, and GitHub is the source of code for deploys. The same repository runs anywhere a container runs. If you start without GitHub, floo projects create makes a repository floo hosts, and floo projects clone checks it out.
What can the app be written in?
Retool's new apps are React, and their server-side functions are TypeScript that runs on Retool's backend. Its import guide accepts React frontends with Node.js or Supabase backends, imports Next.js on a best-effort basis, and lists Python, Ruby, PHP, Go, and Rust backends, and custom auth, as unsupported.
floo builds every service from a Dockerfile in your repository. An app can have a web service, a worker, and cron jobs that run in either image. If your agent reaches for a Python backend because the data work is in pandas, that is fine.
How do people and agents get in?
Retool's strength here is real: every generated app inherits the organization's SSO, role-based access, and audit logging. Custom SSO is listed on Enterprise.
On floo, one line in config, access_mode = "accounts", puts hosted sign-in in front of the app. You invite people with floo apps invite, and your code reads who they are from the X-Floo-User-Email header. For an agent that needs to call the app, you declare which routes accept a key, then mint a key for a named consumer:
floo apps consumers create stock-agent
floo apps keys create stock-agent --consumer stock-agent --scope inventory.write --rate-limit-rpm 60
The key works only on routes with that scope, is rate-limited, and can be revoked without touching any other key. floo strips it before the request reaches your code and passes the consumer's identity instead. See how to give your agent its own API key.
Where is Retool stronger?
- Connecting to what you already have. A Retool resource is a saved connection to a database or API, and Retool proxies queries to it server-side. For a panel over the company's existing Postgres database or REST APIs, that is less work than writing a backend.
- Governance from day one. SSO, role-based access, and audit logging come with every app.
- Retool Agents and Workflows. Retool runs LLM agents that call workflows and functions, and Workflows schedule jobs, alerts, and ETL.
- App user SSO. floo does not offer SAML or OIDC for app users yet.
Which should you choose?
Choose Retool when the tool is an admin panel or dashboard over systems your company already connects to it, and inherited governance matters more than where the code runs. Choose floo when your agent writes the software as a normal codebase you want to keep: a stack it picks, a repository you own, sign-in for the people who use it, and its own key for the agent that operates it.
For a worked example, see the inventory software for a Lego business. For the wider field, see the best platforms to host internal tools built with AI, and when to replace a SaaS tool with software your agent builds.
Sources
- Retool: homepage, apps overview, classic app comparison, build from anywhere, CLI, CLI reference, MCP server, import an app, AI app generation, resources, Retool Database, Retool Storage, Workflows schedules, Agents, Source Control, environments, publishing, pricing
- floo: app sign-in, app API keys, Dockerfiles, Postgres, Redis, storage, cron jobs, preview environments, agent setup, quickstart
Frequently asked questions
Can my own coding agent build a Retool app?
Yes. Retool's CLI lets a local agent build Retool-native React apps on your machine, then push and publish them to Retool. With Retool's MCP server, Retool's own agent writes the code instead. Either way the app's server-side functions run on Retool's backend.
Can I bring an existing app into Retool?
Partly. Retool's import supports React frontends with Node.js or Supabase backends, and Next.js on a best-effort basis. Its docs list Python, Ruby, PHP, Go, and Rust backends, and custom auth, as unsupported.
How is floo different from Retool?
On floo the app is ordinary code in your repository, built from a Dockerfile in any stack. floo deploys it from GitHub and adds invite-only sign-in, managed Postgres, cron jobs, storage, preview environments, and a scoped API key per agent from floo.app.toml.
When should I stay on Retool?
When the tool is a panel over databases and APIs your company already connects to Retool, and you want every app to inherit your organization's SSO, role-based access, and audit logging without extra work.
Does floo support SSO for the people using an app?
Not yet. Invited people sign in with a floo account, including Google. SAML or OIDC sign-in for app users is not available today.