Best Practices for Integrating Retool with Supabase Branching

Hi Retool Community,

I'm working on integrating Retool with our Supabase-backed project and am interested in best practices for incorporating Supabase Branching into our workflow, especially with Retool involved. Our aim is to manage both Retool & Supabase in a single GitHub repository for streamlined development.

  • Is it possible to store other code alongside Retool's code when using Source Control?
  • Has anyone integrated Retool projects with Supabase Branching?
  • Any tips on synchronizing changes between Supabase preview branches and Retool apps?
  • Are there any pitfalls or key considerations?

Would love to hear your thoughts or experiences on this.


Hello @tristdrum,

When integrating Retool with Supabase and managing both in a single GitHub repository, here are some best practices and considerations:

  1. Storing other code alongside Retool's code:

    • Retool's source control feature allows you to store your Retool app's code in a GitHub repository.
    • While it's possible to store other code in the same repository, it's recommended to keep Retool-specific code separate from your Supabase backend code for clarity and organization.
    • You can create separate directories within the repository, such as retool-apps/ and supabase-backend/, to maintain a clear separation.
  2. Integrating Retool projects with Supabase Branching:

    • Supabase Branching allows you to create preview branches of your database schema and data.
    • When working with Retool, you can configure your Retool app to connect to the appropriate Supabase preview branch based on the current development branch.
    • Use environment variables in Retool to dynamically set the Supabase connection URL based on the active branch.
  3. Synchronizing changes between Supabase preview branches and Retool apps:

    • When making changes to your Supabase schema or data in a preview branch, ensure that your Retool app is updated to reflect those changes.
    • If you modify the database schema, update the corresponding queries and components in your Retool app to match the new structure.
    • When merging changes from a preview branch to the main branch in Supabase, make sure to update the Retool app's connection URL to point to the main branch.
  4. Key considerations and pitfalls:

    • Be cautious when making schema changes in Supabase preview branches, as they can affect the functionality of your Retool app.
    • Ensure that your Retool app is compatible with the schema and data changes made in the Supabase preview branch.
    • Regularly test your Retool app against the Supabase preview branch to catch any issues early in the development process.
    • When deploying changes to production, make sure to update the Retool app's connection URL to point to the production Supabase instance.
  5. Additional tips:

    • Use meaningful branch names in both Supabase and your GitHub repository to easily identify the purpose of each branch.
    • Implement a robust testing and review process to ensure the compatibility and stability of your Retool app and Supabase backend.
    • Consider using a continuous integration and deployment (CI/CD) pipeline to automate the deployment of your Retool app and Supabase changes.

Hope this helps.



Hey @PatrickMast !

Have you personally used one repo for more code than just Retool's source control?

That was the biggest unknown, and I'm not on Enterprise at the moment so cannot test it myself :see_no_evil: :joy: