Managing Resources Across Multiple Retool Instances (Separate Servers)

🤝 Discussion
1

Hi all,

Looking for some advice from teams running multiple Retool instances on separate servers (not just the built-in Dev/Stage/Prod environments).

Our setup:

  • Retool Dev → hosted on Docker on its own linux server named RETOOLDEV

  • Retool Prod → hosted on Docker on its own Linux server named RETOOLPROD

  • We use Git (source control) for all apps, queries, and resources (protected branches and controlled promotion flow)

Goal:
We want a clean SDLC:

  • Build in Dev

  • Promote to UAT / Test / Train for business validation

  • Promote to Prod (read-only from a dev perspective)

No manual changes during promotion. No breaking resource bindings.

The Challenge

This works fine when it's a simple Dev → Prod setup using consistent resource names.

However, it becomes tricky when introducing additional environments:

Example:

  • Dev instance has:

    • 3E_DEV

    • 3E_TEST

    • 3E_UAT

    • 3E_TRAIN

  • Prod instance only has:

    • 3E (live production system)

We don’t necessarily want to replicate all lower environments in Prod, but we still need:

  • Apps to promote cleanly via Git

  • Queries to resolve the correct resource automatically

  • Zero manual reconfiguration post-deploy

What We’re Exploring

  1. Consistent resource naming across instances

    • Works for simple setups

    • Breaks down when environment parity doesn’t exist

  2. Dynamic resources (via fx)

    • Potentially allows runtime switching

    • Concern: adds complexity and risk if not tightly controlled

  3. Environment-based configuration

    • Possibly via Git or external config

    • It's not clear how others are implementing this cleanly in Retool

Key Questions I have

  1. How are you handling resource mapping across separate Retool instances?

    • Especially when Dev has more environments than Prod

  2. Do you replicate all environments (UAT/test/train) in every instance?

    • Or do you abstract this somehow?

  3. Are dynamic resources a viable long-term approach?

    • Or do they introduce more problems than they solve?

  4. How do you enforce a proper promotion model?

    • Dev → UAT/Test → Prod

    • Without manual intervention

  5. Is there a clean way to make production effectively “read-only” for developers?

    • i.e., prevent app/query/resource edits in Prod

    • While still allowing end users full functionality

  6. Has anyone successfully used environment variables (via Git or Retool) for this?

    • If so, how are you structuring it?

What “Good” Looks Like for Us

  • Git-driven promotion only

  • No manual resource switching

  • No environment-specific code changes

  • Clear separation of concerns between Dev and Prod

  • Controlled, predictable deployments

I would really appreciate hearing how others have solved this, especially at scale or in regulated environments, and I am sorry for the long read!

Thanks in advance.

Steve

4

Hey @SteveLewis thanks for posting this! I've moved it to the Discussion category so it stays open for others to chime in and share! :+1: