Reliability

<< Click to Display Table of Contents >>

Navigation:  Low-code Process Automation > Studio Cloud - Authoring environment > Bizagi Studio Cloud Services >

Reliability

Overview

Studio Cloud Services is committed to delivering 99.9% SLA uptime. Bizagi Studio Cloud Services uses Web Apps technology that encompasses the Azure App Services' global infrastructure. This true cloud technology lets Bizagi assure the reliability of your Studio Cloud Services.

 

The infrastructure behind the service is designed for availability and resiliency, and this includes storage, networks, and communications. Bizagi conducts 24x7 monitoring on the services and underlying technology with regions around the world where data centers are located, to provide higher performance and meet data location requirements.

 

Web apps technology - true cloud

Studio Cloud Services infrastructure is built using Azure App Services. Compare to a single Virtual Machine, a web app uses a full stack of active dedicated servers where the web app can run. These servers are pre-provisioned in a data center of the Azure region that you choose for your service where the Bizagi web apps are provisioned.

 

Therefore, if one server suffers a failure, the web app is redirected to another pre-provisioned and warm server. So users do not see any downtime in the service. Web Apps only contains the logic and functions layer underlying a web application, for example, to run the Work Portal. Data and other confidential information are not stored in any web app but in the database. All the servers of one web app are located within the same Azure region.

 

Database and storage reliability

One of the most important components in Studio Cloud Services is the storage layer and the database. Reliability is designed for all underlying services of Studio Cloud Services and especially enforced through a highly available storage layer, which is set up by making the most out of replication and data redundancy mechanisms. Bizagi configures the storage layer based on two reliability principles: redundancy and backups.

 

Database reliability

The Studio Cloud Services offers uses Azure SQL Database as its database engine, which is designed with native high availability and resilience capabilities.

Each database is composed of data files and transaction log files that are automatically managed by the platform. These files are stored in storage accounts with Local Redundancy Storage (LRS) within the same Azure region, maintaining multiple synchronous replicas to ensure data durability in the event of hardware failures.

Additionally, Azure SQL Database implements internal mechanisms such as:

Automatic replication within the region

Transaction management with ACID integrity

Automatic failover without manual intervention

 

These capabilities ensure service continuity and minimize the risk of information loss.

 

Backup Strategy

As part of its data protection model, Bizagi implements the backup strategy managed by Azure SQL Database, which includes:

 

Transaction log backups every 5–10 minutes

Differential backups approximately every 12–24 hours

Full backups on a weekly basis

 

All backups are stored using Local Redundancy Storage (LRS) within the same Azure region.

This strategy ensures database recovery in scenarios such as:

Operational failures

Data corruption

Accidental deletions

 

BizagiCloud02_st

 

Retention and Restore Policy (Point-in-Time Restore – PITR)

The service supports point-in-time restore (PITR) capabilities, allowing the database to be restored to any specific moment within the configured retention period.

In development environments, a retention period of up to 35 days is configured. During this period, it is possible to restore the database to any point within the defined window.

This functionality provides a high level of flexibility for recovery from human errors or logical failures.

 

 

Storage redundancy

Bizagi uses cloud storage for tables and files that are replicated with Geo-redundancy (GRS) to protect against hardware failures and increase system reliability. The GRS first copies the data in a local region synchronously, and then asynchronously moves these physical copies to a second paired region.


Last Updated 4/15/2026 9:44:34 AM