Retool enables developers to quickly build internal tools and applications, but managing complex software development lifecycles (SDLC) across multiple environments can be challenging, especially for larger teams. Source Control, available for self-hosted Enterprise Retool deployments, allows syncing apps, resources and queries across multiple instances. This supports advanced multi-stage development workflows with separate development, staging, and production environments. This article dives deep into architecting multi-instance Retool deployments with Source Control to enable Enterprise-grade development lifecycles.
Setting Up Multi-Instance Retool Environments
The first step is deploying separate Retool instances for development, staging, and production environments. To make the Retool containers stateless and independently scalable, [externalize the Postgres database that stores Retool's application data. This allows scaling Retool instances based on the different usage patterns of developers vs end users.
For example, provision three Retool instances with shared backend storage:
- `retool-dev.company.com`: Development environment
- `retool-staging.company.com`: Staging/QA environment
- `retool-prod.company.com`: Production environment
Configuring Source Control for Multi-Instance Development
Next, set up a Git repository for each Retool instance. Protect foundational resources like data sources and environment configs in all instances. For the development instance, enable developers to work on feature branches.
Here's an example Source Control setup:
- `retool-dev`: Developers collaborate on feature branches
- `retool-staging`: Admins review and merge pull requests from dev
- `retool-prod`: Admins promote changes from staging to prod
Development Workflows with Source Control
With multi-instance Source Control configured, development teams can follow structured workflows:
1. Developers build apps and queries on feature branches in the dev instance. For example:
`git checkout -b "new-crm-integration"`
2. When ready, developers open pull requests to merge their feature branches into the staging instance. This allows others to review changes and conduct integration testing.
3. After validation, admins merge the staging branch into the prod instance via PR. This deploys the changes to end users in a controlled manner.
4. If bugs or issues arise, admins can quickly roll-back the production instance to a previous stable state by reverting commits.
Best Practices for Complex SDLC with Retool Source Control
To optimize multi-instance development workflows with Source Control:
- Establish a clear branching strategy like Git Flow with main and development branches
- Set up protected branches for staging/prod with mandatory PR reviews
- Implement granular access controls to restrict who can deploy to production
- Monitor Source Control events to audit the flow of changes across instances
- Consider automating deployments between instances using CI/CD pipelines that listen for PR merges
Architecting multi-instance Retool deployments with Source Control enables large development teams to follow structured, Enterprise-grade SDLC practices. By externalizing state, setting up staging environments, and configuring advanced Git workflows, organizations can build and ship internal tools in a scalable yet controlled manner.
However, multi-instance deployments do come with increased DevOps overhead and hosting costs to manage. Security and compliance is also crucial when moving application code across environments. But for many enterprises, the productivity benefits of Retool's low-code platform combined with the safety of Source Control unlocks a new paradigm for internal tool development at scale.
What are multiple instances of an application?
Building in low-code is no different from building applications with code. You need to test the features you're adding frequently. While building them, you can break interfaces. That's why software development relies on the sacred trinity of instances: dev, stage, and prod. The production instance of the application is where your users are; it's live and operates 24/7. The dev environment is used to break things, add cat memes, and use lorem-ipsum texts. Once a feature is finished in the dev environment, it is either deployed directly to prod for small-scale projects, or, for larger projects, we use a third environment: stage. The stage environment usually contains outdated and often anonymized data from prod, so no more cats or lorem ipsum. Here, we are almost in production, and we can deeply test the application with near-real data. We can run stress tests, security audits, and performance tests.
To be honest, there are often even more instances. Integration is used specifically to test connections between your application and the rest of your tools and software. In some cases, we can even have one instance per feature, so each can be tested independently first to avoid long hours of debugging multiple merged features that impact each other.
