I was very disheartened, after a month of learning the app and building something, to learn about the user /licensing structure - in that, I thought (wrongly) for $10 per user per month - I could let our users access what we have built and not worry about them breaking it.
I’ve since learned that is not the case. There is a premium of $40 per user per month to essentially stop users doing this. This really changes things, as it becomes a lot more expensive.
We created an internal tool. Only one of us developed it and will develop it - and we want the rest of the company to use it. Some will use it once a month. Some every day - but at $600 per user per year; then we obviously are not going to pay that for those who will use it less than 10x a year.
So - if Im not mistaken; I could just have one user - the person developing the app on the top tier. And then just create a public link, with a password, and that would allow everyone in our company to use the app, right?
I’m not too fussed that the link could be shared - I think we can knock up a quick n dirty “password wall” to get in the app….. if the overall password doesn’t work. And also so we know which ‘users’ use it
Would that work?
It’s a real shame - because retool will get $50 per month off me and “1 user” vs potentially 10-15users at $100-150 per month - and tbh. I’d pay more for a ‘middle tier’.
Technically it is possible to create a public link with a password for others in your company to use the app, but it is not recommended from a security standpoint. Retool is not designed to be very secure, and any safeguards you put in place can likely be lifted with enough effort.
Another option, which may or may not be allowed by the terms of service, is to have a separate retool user for different roles within your company (e.g. managers and employees) and then build a simple login for your users to access and log user-specific data. This approach would be more secure as your app would not be publicly exposed, but it may be a bit more cumbersome for users as they would have to go through two logins to use the app.
Please be aware that with both of these approaches, you would lose access to some of Retool's auditing features and would have to handle your own user-specific queries.
I hope this information is helpful. If you have any further questions, please feel free to ask.
No, with the second method everyone will be on the 50$/Month subscription but instead of creating a user for every person, you’ll have one user for every role and then a custom login system on top of it to handle user specific stuff.
Hi Neil, I feel your pain. This situation is even worse if your use case requires the self-hosted version of Retool. In that pricing structure there isn't even a $50 tier to choose from. The simple need to prevent users from being able to edit jumps pricing from $10ea to 5 figures plus! I've been vocal about this before. If Retool weren't so darn awesome/easy/powerful I would have dropped it because of this reason, but instead, I make do (although this issue does limit what I can/will do with the platform).
Another option for you is to inject CSS that hides the menu bar and floating nav. This makes it appear to users of the app that things are view only. Eliminates the temptation to go exploring. Obviously, this isn't real security and a smart/persistent user could pretty easily find their way to the edit page, but this is what I do while I wait/hope for a better solution and it works well enough for my company.
This is what I'm currently using to hide the nav bar and clean up the top of the screen, and also hide the floating nav. YMMV, I don't know if the div names will be different in the online version, and I've also had to tweak this once or twice after updates. Should be straightforward to find the new/correct div names in the dev tools of your favorite browser. I set it per app under scripts and styles. This is the only option I've found, the public app option also isn't available (for now?) for those of us on self-hosted without being on the enterprise plan.