Retool Client Portal Pricing: What You Need to Know

If you've been researching Retool client portal pricing, you've probably hit the same wall as dozens of teams in the Retool community: the platform is excellent for internal tooling, but its per-seat pricing model gets expensive fast when you need to expose an app to hundreds or thousands of external customers. This post breaks down exactly how Retool's pricing works for customer-facing portals, what's possible today, and how to architect around the limitations.

Why Retool's Default Pricing Doesn't Fit the Client Portal Use Case

Retool's standard pricing is built around the assumption that every user is a builder or an internal operator. At $50 per user per month on the Business (Pro) plan, that's a reasonable cost when you're licensing it for a team of 10 engineers or ops staff. But the moment you try to expose an app to 500 customers — each of whom just needs to check their order status or view a report — that math breaks down immediately.

The frustration is compounded by the fact that ACL (Access Control List) features and permission groups — the exact tools you need to securely show users only their own data — are locked behind the Business plan. So you can't even build a secure, multi-tenant portal on a cheaper tier.

• Free / Team plans: No granular permission controls, no permission groups, limited for external use
• Business plan ($50/user/month): Full ACL, permission groups, and public apps — but every authenticated user counts toward your bill
• External users: There is currently no discounted "viewer" or "portal user" pricing tier

What Are Retool Public Apps — and Can They Solve This?

Retool does offer a feature called public apps on the Business plan. A public app is accessible to anyone with the URL — no Retool account required, and those anonymous visitors do not count toward your user license. On the surface, this sounds like the workaround you've been looking for.

But here's the critical limitation: public apps have no authentication layer. Because Retool doesn't track any user identity on public apps, you can't do any of the following:

• Show a customer only their own orders or records
• Use current_user.email or any user-specific variable to filter data
• Gate access to sensitive operations like editing or deleting rows
• Use any Retool-native permission groups to restrict what different users can see

Public apps are best suited for genuinely public dashboards — think a read-only status page or a marketing-facing report. If your customer portal needs to show personalized, private data, public apps aren't the right tool.

The Embed Workaround: Using /app/ with External Auth

The closest thing to a true client portal today is embedding the standard /app/ URL in your own web page. Here's how this pattern works:

• Step 1: Build your portal app in Retool as a normal app (not a public app)
• Step 2: Create Retool accounts for your external users — each one will count as a billable user on your plan
• Step 3: Use permission groups to restrict what each external user can see and do inside the app
• Step 4: Embed the /app/your-app-name URL in an iframe on your customer-facing website
• Step 5: Unauthenticated visitors will be prompted to log in via Retool's standard auth flow before accessing the app

This approach gives you real authentication and real data isolation — but every external user needs a Retool account, and at $50/user/month, the cost scales linearly with your customer count. For a small set of high-value clients (think B2B SaaS with 20–50 key accounts), this can absolutely make sense. For a consumer-facing portal with thousands of users, it's a non-starter.

How to Decide If Retool Is Right for Your Portal Today

Before committing to Retool for a client portal, run through these questions:

• How many external users do you have? Under 50 high-value accounts? Retool's embed approach is viable. Thousands of end users? The per-seat cost will likely exceed purpose-built portal tools.
• Does each user need to see private, personalized data? If yes, public apps won't work — you need authenticated sessions and current_user variables.
• How complex is the UI logic? Retool's component library and query builder are genuinely best-in-class for data-heavy interfaces. If your portal is largely CRUD operations on a database, Retool's builder speed is hard to beat.
• Are you already paying for Retool internally? If your team is already on a Business plan, adding a handful of external client users is a marginal cost — not a new budget line item.

What's on Retool's Roadmap for External Users?

As of the community thread that inspired this post, Retool's product team has acknowledged this gap and confirmed they are actively exploring a dedicated external user or client portal pricing model. A Retool PM reached out directly to users who flagged the issue, which suggests it's being taken seriously. However, no public timeline or specific feature announcement has been made.

If this is a blocker for your team, the best move is to email Retool's product team directly (as suggested in the community thread) and share your specific use case — volume of external users, data sensitivity requirements, and budget constraints. Product teams prioritize features with real customer demand behind them, and your input genuinely matters.

The Bottom Line

Retool client portal pricing is a real friction point. The platform's power is undeniable, but the current model assumes every user is an internal operator. If you're building for a small set of external accounts, the embed + permission groups approach works well today. If you're building for a large external user base and need authenticated, personalized access, you're either waiting for Retool to introduce a portal-specific pricing tier — or you're looking at a hybrid architecture where Retool handles the internal admin side and a lighter tool handles the customer-facing layer.

Watch Retool's changelog and community forum closely. This is one of the most-requested features in the ecosystem, and it's a matter of when, not if.