Choosing Between Multiple Sites and Separate Deployments in Bold BI

Most organizations maintain multiple application environments such as Testing, UAT, and Production to support software development, testing, validation, and release processes. While these environments often share the same dashboards and application logic, each environment typically connects to a different database, API endpoint, or backend service.

A common question for administrators is: Should Bold BI be installed separately for each environment, or can a single Bold BI deployment support multiple environments?
The answer depends on your requirements for infrastructure isolation, security, compliance, administration, and maintenance.

This article explains:

1. When to use Multiple Sites within a single Bold BI deployment.
2. When to use Separate Bold BI Deployments.
3. How to manage users and permissions across environments.
4. How to promote dashboards from Testing → UAT → Production.
5. Common deployment patterns and recommendations.

Quick Decision Guide

Use the following matrix to determine the most suitable deployment model:

Option 1: Using Multiple Sites in a Single Bold BI Deployment

Bold BI supports multiple sites within a single deployment. Each site has its own database and manages its dashboards and resources separately from other sites, so dashboards, data sources, and users in one site are isolated from another.

Each site can represent an environment:

1. Testing
2. UAT
3. Production

Although sites share the same Bold BI infrastructure, each site maintains its own:

1. Dashboards
2. Data sources
3. Categories
4. Users
5. Permissions

Example environment mapping:

• Testing site → Testing database
• UAT site → UAT database
• Production site → Production database

Benefits:

1. Easy dashboard promotion between environments
2. Simplified maintenance
3. Single upgrade process
4. Centralized administration

Bold BI Deployment
│
├── Testing Site
│     └── Testing Database
│
├── UAT Site
│     └── UAT Database
│
└── Production Site
     └── Production Database 

Configuration Setups

1. Step 1: Create Sites Navigate to Site Management → Create Site, create Testing, UAT, Production sites.
2. Step 2: Configure Environment-Specific Data Sources
   For each site:
   • Configure a data source that points to the appropriate environment database.
   • Use the same data source name across environments whenever possible
   • Use consistent data source names makes dashboard promotion easier.
   • For more information, refer to the help documentation
3. Step 3: Develop and Validate
   • Build dashboards in Testing site
   • Validate them and then publish to Testing → UAT → Production
   • For more information, refer to: Multi-Tenancy in Bold BI.

Option 2: Using Separate Bold BI Deployments

Separate deployments should be used only when a higher degree of isolation is required.

Typical examples include:

1. Customer-hosted deployments
2. Government environments
3. Healthcare systems
4. Air-gapped networks
5. Contractually isolated customer environments

When to Choose This Approach

Use separate deployments when:

1. Infrastructure must not be shared.
2. Security policies require complete isolation.
3. Customers require dedicated hosting.
4. Compliance regulations require physical or logical separation.
5. Upgrade schedules differ across environments.

Benefits

1. Complete isolation
2. Independent administration
3. Separate upgrade schedules
4. Dedicated infrastructure

Bold BI (Testing)
│
└── Testing Database


Bold BI (UAT)
│
└── UAT Database


Bold BI (Production)
│
└── Production Database 

Managing Users, Groups, and Permissions

When using multiple sites, users and groups can be given access only to the sites and resources relevant to their role. Bold BI provides resource-level permissions — Read, Write, and Delete — for dashboards, data sources, and other resources, so access can be scoped per environment.

• Users can be added to Groups, and permissions can be assigned at the group level to manage access for multiple users at once.
• A user can also be invited into a site from another site (using the same email address); once invited, that user can access resources in both sites after being granted the required Read/Write/Delete permissions.

This allows, for example, developers to have Write access in the Testing site while only having Read access in Production, with a smaller group of release approvers holding Write access in UAT and Production.

For more information, refer to Managing Permissions in Bold BI and Managing Groups in Bold BI.

Publishing Dashboards Between Environments

Bold BI’s Publish feature lets you move a validated dashboard (and its associated data source) from one site to another, which is a natural fit for promoting a dashboard from Testing → UAT → Production after each stage is validated.

The publish dialog behaves slightly differently depending on the site:

• From the master site (the first site created in your Bold BI deployment), you’re offered a choice between Internal Site (other sites on the same Bold BI server) and External Site (sites on a different Bold BI server).
• From a non-master site, the external-site publish dialog is shown directly, and it’s also used to reach other internal sites.

To publish a dashboard from Testing to UAT, for example:

1. In the Testing site, open the dashboard’s action menu and select Publish.
2. Choose Internal Site, then select UAT as the destination.
3. Confirm the category and naming options, then submit.
4. Repeat the same steps from UAT to Production once the dashboard is validated in UAT.

Use External Site publishing only if you need to move a dashboard to a site hosted on a different Bold BI server — for example, publishing from your main deployment to a customer’s dedicated, separately hosted Bold BI instance.

For detailed configuration steps, refer to Publish Dashboards in Bold BI.

Common Deployment Patterns

Pattern 1: Standard Enterprise Deployment

The most common deployment model for organizations managing multiple application environments within the same infrastructure.

Bold BI Deployment
│
├── Testing Site
├── UAT Site
└── Production Site 

• One Bold BI deployment
• Separate sites for Testing, UAT, and Production
• Each site connects to its corresponding database or endpoint
• Dashboards are promoted between environments using the Publish feature
• Centralized administration, upgrades, and maintenance

Best for: Organizations that need environment separation but can share the same Bold BI infrastructure.

Pattern 2: Hybrid Deployment

A combination of shared and dedicated deployments that balances operational efficiency with customer isolation requirements.

Shared Bold BI Deployment
│
├── Testing
├── UAT
└── Production

Dedicated Bold BI Deployment
└── Customer A

Dedicated Bold BI Deployment
└── Customer B 

• One shared Bold BI deployment for internal environments such as Testing, UAT, and Production
• Separate Bold BI deployments for customers requiring dedicated hosting
• Internal teams manage dashboards through the shared deployment
• Dedicated customers maintain complete infrastructure isolation

Best for: SaaS providers and software vendors supporting both shared-hosting and dedicated-hosting customers.

Pattern 3: Dedicated Customer Deployment

Each customer receives their own independent Bold BI environment.

Customer A
└── Dedicated Bold BI

Customer B
└── Dedicated Bold BI

Customer C
└── Dedicated Bold BI 

• A separate Bold BI deployment per customer
• Customer-specific databases, dashboards, and resources
• Independent administration and upgrade schedules
• Complete separation from other customer environments

Best for: Customers with strict security, compliance, contractual, or data residency requirements.

Recommendation

For most organizations, Multiple Sites within a Single Bold BI Deployment is the recommended approach.

Use this model when:

1. Environments differ only by database, endpoint, users, or permissions.
2. Infrastructure can be shared.
3. Centralized administration is preferred.

Choose Separate Deployments only when:

1. Complete infrastructure isolation is required.
2. Security or compliance policies mandate separation.
3. Customers require dedicated hosting.
4. Independent upgrade cycles are needed.

Conclusion

Selecting the right Bold BI deployment strategy depends on the level of isolation required between environments. For most organizations, multiple sites within a single deployment provide a centralized and cost-effective way to manage Testing, UAT, and Production environments.

When dedicated infrastructure is required, separate Bold BI deployments offer complete separation of resources and access. With support for environment-specific data connections, granular permissions, and dashboard publishing, Bold BI enables organizations to implement a reliable analytics lifecycle from development through production while meeting both operational and security requirements.

Additional References

• User Guide Documentation: Multi-Tenancy in Bold BI
• User Guide Documentation: Managing Permissions in Bold BI
• User Guide Documentation: Managing Groups in Bold BI
• User Guide Documentation: Publish Dashboards in Bold BI