We started Retool to help developers build internal tools faster—and along the way noticed that a lot of the same frustrations with complexity, costs, and data risks applied to building software for external users too. Developers are often forced to build from the ground up: setting up a database from scratch, integrating multiple APIs, configuring the latest Webpack release and making it work in CI, fiddling with CSS to get components to fit company branding, and then managing auth, SSO, permissions, scaling, performance—the list goes on.
So, we’re introducing two new products. Retool Portals is great if you want whitelabel Retool and have it manage login, signup, and user management; Retool Embed makes sense if you want to augment an existing portal with the functionality you build in Retool.
I’d love your feedback on how to make these even better. Also happy to answer any questions.
- Retool is datastore/backend-agnostic, so from a backend/data perspective it will be as scalable as whatever backend you’re using to process/store those orders. You can connect Retool to make requests to your own API, to directly query a database, etc.
- From a frontend perspective, you can choose to deploy Retool using Retool’s Cloud, or self-host Retool on your own private cloud. The former is quite scalable, but if you wanted full control over scalability you’d likely opt to self-host. If you’re self-hosting you have all of the “typical” scaling techniques available to you: you can e.g. run Retool on Kubernetes, and vertically or horizontally scale however you need.
For more on scaling self-hosted deployments, see: https://docs.retool.com/docs/horizontally-scaling-retool
Retool embed reminds me a bit of Matterway in spirit. But also a bit like Pixiebrix.
