Retool due diligence: vendor lock-in and licensing

đź’¬ App Building
1

Hello Retool team — following up on the discussion in this thread

We're evaluating Retool as a low-code option for building an internal CRM. Important context: our authentication, authorization, and access control are already fully implemented in our GraphQL backend, and we want to keep that 100% independent of any vendor-managed auth/session layer.

I'd appreciate confirmation on the following points (ideally with product-specific behaviour for Cloud vs Self-hosted if it differs):

1) Public access + custom auth (no vendor-managed auth)

  • Can a Retool app be made publicly accessible(internet-facing) while still using only our custom auth(i.e., Retool does not manage sessions/users)?

  • If an app is public, do requests from the browser reach our backend directly, or do they first go through Retool infrastructure (Retool servers / Retool-managed proxy / Retool-managed auth/session layer)?

  • If Retool requires any Retool-managed session/cookies/users for app access, please confirm what is mandatory vs optional.

2) Direct GraphQL calls (no proxy / no third-party layer)

  • Can the CRM frontend call our GraphQL endpoint directly from the client(browser → our API), without requests being proxied through Retool or any third-party layer?

  • If Retool does proxy by design in some modes, can we disable it? If not, what's the exact routing in:

    • Retool Cloud

    • Retool Self-hosted

### 3) User tracking + pricing implications

  • Does Retool track/count how many unique users access the app (especially if we use our own auth and do not want Retool-managed users)?

  • How does licensing work for our scenario:

    • "Internal users" (employees building/using the CRM)

    • "External users" (if we ever expose parts to partners/clients)

  • What does internal and external users means w.r.t retool pricing page [see)](Retool | Pricing).

  • If the app is public or uses custom auth, how does Retool define a "user" for billing/limits?

### 4) Advanced GraphQL capabilities

Does Retool have native support for:

  • GraphQL subscriptions (real-time updates)

  • Client-side caching / cache invalidation strategies

### 5) Security / vendor independence details (to avoid hidden coupling)

  • Can we run Retool in a mode where Retool never needs our user identity, and only sees API calls as "opaque" traffic?

  • Are there any required Retool components (e.g., Retool-managed auth headers, Retool identity, Retool gateway) that would create vendor lock-in for auth/access control?

Thanks — we're specifically trying to avoid any architecture where Retool becomes part of our identity/security boundary.

3

@shawn_optipath @pyrrho @Tess @jack_t

4

Hi @apoorv-2204,

To answer your questions:

Can a Retool app be publicly accessible without Retool-managed auth?

No, Cloud always requires a Retool user session to access an app.
Self hosted still requires Retool Authentication to access apps.

Do requests go directly to your backend?

Retool Cloud: Browser → Retool servers → Your backend
Retool Self-hosted: Browser → Your self-hosted Retool instance → Your backend
There is no built-in "pure browser -> API" mode for Resources.

If you want:

Browser → Your GraphQL API directly

There are only two ways:

Option A — Use Retool "Frontend JS" with fetch()

You can technically:

  • Not use a Resource
  • Use a JS query
  • Call fetch("https://your-api.com/graphql")

But:

  • You must deal with CORS
  • Your API must allow browser-origin requests
  • Secrets cannot live in the frontend
  • You lose Retool’s resource management features

This becomes a normal SPA architecture.

Option B — Build a custom React app instead

If full control and zero proxy is required, Retool may not be the right tool.

Retool is designed to sit between frontend and backend.

That’s intentional.

Retool defines a “user” as:

Anyone who logs into the Retool app environment.

It does not matter:

  • Whether you use your own backend auth
  • Whether you ignore Retool permissions

If someone accesses the app UI and authenticates into Retool, they count.

Internal vs External Users (Pricing Context)

Internal users
Employees inside your organization using Retool apps.

External users
Users outside your org accessing apps via the External Users feature (different pricing tier).

Even if your backend controls permissions, if they log into Retool, they are counted.

There is no “anonymous unlimited public usage” model like a traditional web app.

Retool is licensed per user.

No native first-class support for GraphQL subscriptions (WebSocket-based real-time).

You’d have to implement custom JS + WebSocket logic manually.

Retool is primarily request/response oriented.

Client-side caching

Retool does not behave like Apollo Client.

It does not provide:

  • Normalized cache
  • Automatic cache invalidation
  • Subscription-aware cache updates

It provides:

  • Query result caching
  • Manual refetch
  • State management via components

This is not a full GraphQL client framework.

Can Retool run in a mode where it never needs our user identity?

No. Retool always maintains:

  • A Retool user identity
  • A Retool session
  • App-level access control

Does Retool become part of our identity boundary?

Yes — at the UI access layer.

Even if:

  • Your GraphQL enforces 100% of data authorization
  • Retool has zero role logic

Retool still gates access to the app itself.

That is architectural coupling.

Architectural Reality

Retool is not:

• A headless UI renderer
• A static frontend compiler
• A pure SPA framework

It is:

A managed internal app platform with its own user model and session layer.

If your requirement is:

“Retool must not sit inside our identity boundary at all.”

Then Retool Cloud will not meet that requirement.

Self-hosted reduces vendor dependence but still keeps Retool in the request path.

Hope this helps!