Unclear what a "User" in terms of licensing/pricing is

The pricing mentions people with logins, but I don't really care about logins, nor does the information I was presented with make clear who would need a login and for what.

In a hypothetical scenario, where five developers would produce Retool apps, and 500 service worker employees would access these apps in user mode (assuming no need for granular access controls), would that count as 5 users or as as 505 ?

If the answer is the latter, we have many workers who only work few hours a week. Would they each need their own separate login, or is sharing of logins/accounts permitted if, for example, two employees use the same login, but not concurrently ?

Hi JKHST,


Anyone with a Retool account counts as a user pricing-wise, editor or otherwise so it would be 505 users if each one is logging into Retool. As far as sharing accounts non-concurrently, functionally this can work but it's not advised as it is less secure, you lose access control ability, audit-ability of what users are doing, and any user specific logic based on the current_user won't work.

On the Pro plan, you do get the public apps feature, which lets you build apps that are publicly available to anyone with the URL. Whoever uses that link won't need a Retool account, so you won't be charged for them. Since the app is public though, you wouldn't want it to have any user-specific information or dangerous functionality (I.E. deleting rows in a database) or you might want to add some level of security into your app.

Hope this helps and let us know if you have any other questions!

Grace

Thanks, this clarifies things for me as well.

For public facing apps, what specifically could one do to "add some level of security"?

One idea I just came up with is provide a URL with a username/password in the querystring to do an old school plain text authentication (knowing all that implies good and bad). On page load the app check the database for authentication and then you could also use that for current_user logic to lock the user into specific records or whatever.

Have not used any authentication in Retool yet, but maybe the app could OAuth into some other service and only becomes functional with a valid response? Again, you have current_user simulated.

Other ways?

Sorry I do not mean to tell others how to take food out your mouths! But the $10 to $50 price jump for Pro is a little steep for some companies (and cheapskates like me.)

1 Like

As a quick note, current_user could definitely be a great workaround for auth + public apps, but we don't collect any user data on public apps, so there is no current_user object 😅