Adding Workflows to Existing Local Instance


We'd like to get started with Workflows on our self-hosted instance.

I've been following the documentation and it seems to be straightforward...ish...

Our self-hosted Retool is up-to-date, but was setup and configured a year or more ago - so the /retool-onpremise folder doesn't contain things like the docker-compose-workflows-with-temporal.yml file.

I'm wondering, is it simpler/safer to start by pulling down the repository from fresh, and transposing any setup/config/customisations we've made (like SSL config) - and then following the standard documented install procedure? Will our existing postgres dbs etc. retain their data and our solutions?

Any advice would be appreciated, there isn't so much specific detail about adding Workflow to existing deployments so just wanted to gather some intel from the real world.


1 Like

+1 looking for the same i have my self host a year ago but need to add workflows to test it out, any tip? @victoria @PeteTheHeat without loosing current data of course, also im using as the OP my own postgresql etc

The docker compose file just contains the "recipe" to create the containers. More recent releases of Retool on Docker (I think from 3.16?) have workflows enabled by default in docker-compose.yml

If you're on an older release, I think you can just add a couple of lines to your docker-compose.yml file. Here is a list of lines to comment in case you don't want to use workflows, Deploy Self-hosted Retool with Docker Compose | Retool Docs, so in case you'd want to enable it, it should be the other way arround.

Or compare the docker-compose.yml with and without workflows and add the required lines to your own yml file.
Enabling workflows will add a couple more containers and it will add a new database to your server.

1 Like

Thanks, I'll give that a try.

Incidentally, I did try to replace my local repo with the most recent version and transpose my settings but something wasn't quite right - I think with SSL. Just kept getting an error from Ningx (Bad Gateway).

I will try just inserting the Docker compose lines for Workflows and see what that does. I'll report back later.

1 Like

@agaitan026 @mbruijnpff

I've got somewhere... a morning of hacking around with the docker-compose file worked, but it's not exactly plain sailing so I've a support ticket logged separately.

I brought in the necessary container configurations as they appeared in the docker-compose-workflows-with-temporal.yml file. But there were also amendments to be made to the original containers and their config, so that they can work with the temporal/wf containers. So yeah, by going through line-by-line and bringing over anything that looked relevant, I did it.

A few gotchas for our setup...

I had to run the script at the beginning so that it created the retooldb.env file. Our release predates the Retool DB and there seemed to be some kind of dependencies on this so I had to set that up too.

I couldn't transpose the settings for the "postgres:" container. The new .yml specifies an image using "postgres:14.3" whereas our existing docker-compose is set to "postgres:9.6.5". If I included the most recent version, I couldn't get the system back up again.

I had to ignore a configuration line on the "api:" container, under "volumes:" which said: -${BOOTSTRAP_SOURCE:-./retool}:/usr/local/retool-repo (it did not like this reference when bringing up the container).

We're getting this error, but otherwise WFs seem to be working...

There was a lot of confusion around SSL setup. The docco conflicted with what we had setup, so I just left that well alone in the end because it didn't make sense to me. I think it's changed quite a bit since our original implementation/release and when I tried to implement it following the docco as it is today, it just didn't like it.

Awaiting on some feedback from Support who said they're looking in it for me - awaiting them to do a bit of a health-check.


1 Like