Hi, I am trying to scale down my retool instance to save money, biggest issue fo far seems to be available memory.
Looking at the container stats:
Since I dont really use workflows in retool:
Looking at Architecture here, can I simply remove Workflow Backend and Workflow Worker from my Docker Compose?
Possibly also RetoolDB, since I use external PostgreSQL for data?
I am aiming to fit into 8GB ram instance, any other optimalization welcomed...
Hi @johnymachine! Yes, if your app doesn't use workflows then you don't need to run those containers. Just make sure that if you remove them that you don't reference them anywhere.
Since your concern is about available memory, it doesn't look like you'd save much memory on not including retool-db, but regardless if you are only using an external postgres then you don't need to run the retool-db container either.
Based on your numbers that should be sufficient for fitting into 8GB!
So remove this:
and comment this:
Is that all?
You can comment out anything related to temporal as well, since that is purely workflows related. I know the comments say only to comment it out if you have an Enterprise license, but that is assuming you still have workflows set up. In the same way that you wouldn't run your own temporal cluster if you were using a Retool-managed cluster, you wouldn't run it if you weren't using workflows at all either.
But yes the main point is to just not run the workflow-related services and config.
Also found this thread: Self Hosted retool without workflows (and temporal)
From @Cole_Diffin and seems like he is not using code executor either?
Yes the code executor is also only used for workflows 
Seems like code-executor is bit tricky:
Code Executor Sandbox Escape | Retool Docs
Results after migrating to 3.196.19
Next stop is to update 7 years old https-portal: https://hub.docker.com/r/tryretool/https-portal/tags
Great callouts @johnymachine! While it is possible to deploy without the code executor, these security concerns are a recent development to be aware of. I asked around and it is likely going to be required in future stable versions. Luckily it isn't the most memory intensive container.
Also, we recognize that the https-portal is an older image, but our docs are up to date on configuring it for custom certs.
I understand the concern about bundling third-party images, but maybe you could consider providing a Traefik example. It’s a well-established and reputable project, and relying on a 7-year-old Nginx setup feels like a real shame in comparison.
