Bundle Retool as local "install"

I think I might have a slightly odd idea for how to use Retool, but it looks promising!

We run everything on AWS in our company and we have a fairly complex setup with a lot of services which makes development a bit arduous sometimes.
To overcome this we are using Localstack, which is a "stand alone" on-premise Docker environment for running AWS services.

My setup this far in Retool, is to use Retool as a UI for handling the development setup and to be able to "put together" and monitor the services needed for local development.
This means that everything runs locally on Docker and I've created an API in AWS API Gateway (running in Localstack) as the backend for Retool.

Then comes the question on how this can be shared between developers...
I need to spin up the Retool and Localstack containers, of course, but what's the best way to "deploy" to Retool?

Localstack has something called "cloud-pods" that's basically an exported Docker image that we pull on starting the Localstack container, so how would we do something similar for Retool?

Currently I've been trying to export the JSON from Retool and get it to import when you start Retool, but I haven't found a way to do that automatically...

Hey @QAnders - thanks for reaching out! This is definitely an interesting idea. :thinking: If I understand correctly, you essentially want to populate the default Retool image so that it comes preconfigured with all the necessary tooling (resources, apps, etc.) for monitoring the LocalStack container. Does that sound right?

If you are on an Enterprise plan, I can see this being possible with Source Control or the Retool API. The other, more low-level option is to create a backup of your application database that gets piped into the newly created database when initially building everything. That could be done via local script or an augmented image, as I don't think Retool itself will support an "on build" action like that. It would also require that you use a consistent encryption key across all installations.

I hope that gives you a place to start brainstorming, at the very least! Let me know if you have any other thoughts or questions.

Thanks for getting back to me!
Yes, you got it right, I'd like for the container to be spun up and be "pre-installed" with the Retool App.

We have a separate Localstack "container" in each repository (each local directory) as each micro service has different databases, AWS services, etc.
THe setup of the Localstack container is handled through docker-compose and "initialization scripts" that we can add to Localstack (which the Localstack container runs automatically after it has started). These "init scripts" will spin up AWS services, create databases, etc. needed to run the micro-service locally.

Likewise I'd like a Retool container to be used in some repos where it would work as a "developer tool" where you could add AWS services or resources, recreate the DB, and other tasks that might help the developers.
As each repo has different needs it would need to be a dynamic loading of the App in Retool.
Backing up the DB and restoring it after start would indeed to an option, but a bit arduous perhaps...

Another issue might be how licensing works... I would assume it's OK for the same user to run multiple containers with different Apps on them, as long as it's the same user on the same laptop it would be counted as one user?

I wasn't even thinking about this aspect of your proposal, but that is likely going to be the most significant blocker. My post here outlines the primary limitations of deploying multiple instances on a non-Enterprise plan.

Ok, bummer, that blocks my idea then, as we'd have one Retool instance per repository, as I understand your licensing of "instances".

It would be the same App and the same user, though, only different properties for directories and different artifacts (e.g. DB dumps) to import on startup.
I guess that's semantics though and you'd consider it to be multiple instances... :smiling_face_with_tear:

Unfortunately, yeah - deployed instances all perform a license check with our servers on a periodic basis, so reusing the same license key would cause some issues.