Differences reusable

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Differences reusable

VPN setup

With Bizagi PaaS, it is entirely optional to use a VPN and it would be needed for integration purposes (i.e. integration with LDAP, DB sources via Replication or Virtualizationn, ECM not cloud ready, or integrations with systems of record), whenever the applications you want to integrate with, do not offer a service-oriented architecture and use different protocols other than HTTP/HTTPS.

We encourage you to expose all your systems in a demilitarized zone, where Bizagi could integrate without the need of a VPN.


A VPN setup adds an additional cost to the subscription costs.


For more information about VPN setup, refer to Cloud VPN.



Authentication: Bizagi PaaS supports integrating with Identity Management services such as the Open ID Connect protocol. The following authentication methods are supported:

oAzure Active Directory (Azure AD)

oLDAP (this integration requires VPN setup)


If you have any other authentication method, it must be analyzed. For more information refer to Identity managers.


Virtualization and Replication

Data Virtualization and Replications entails some aspects you will need to consider. When integrating an on-premise data source via data Virtualization, Bizagi PaaS will connect to it through its assigned TCP service port, and therefore, you will need a VPN to allow such communication and to implement it with due hardened security measures.  

Access to an external data source over the internet, inherently depends upon different factors which are beyond Bizagi PaaS' control, such as: a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, the quality of the networks used during transmission, etc. All of these factors may affect the overall user experience, and therefore, you will need to mitigate them. Refer to Data virtualization.


Component library

Supported, through consider that you are solely responsible of the code developed in custom components added through this feature.

This entails: watching after an adequate performance while ensuring that locks or issues are not generated, being accountable for uploading secure code, and ensuring that such code is thoroughly tested throughout the different environments, among others.


Consider that components must be self-contained (i.e, all libraries needed by a component must be uploaded via the component library). This means that a component may not rely on driver, DLL, file in general, or connectivity setup that needs to be installed separately into the local machine.


Recall that Bizagi PaaS, as a cloud-centric architecture, is built for scalability among other pillars.

A high scalability in Bizagi PaaS considers that computing power, storage services and other capabilities, are made available on-demand as elastic resources which operate behind a load balancer, and therefore, point-to-point integrations which demand the installation of a component in a specific location is not a best practice.

For this reason, it is important that when integrating your systems and services you can follow modern and service-oriented principles such as using Connectors when applicable.

For more info refer to Bizagi Connectors.



Deployments in cloud environments are performed differently than in on premises projects. Neither one-click-deployment nor Advanced deployment are used.

Please ensure that Customers are familiarized with the cloud-based deployment process described in this article: Export to Cloud.

This understanding is vital to guarantee  the continuous improvement in migrated projects.


New URLs

One lingering question is how the transition to Bizagi PaaS will affect an organization’s URLs. Once your application is running in Bizagi PaaS, each environment will have separate resources which translate into an independent URL, as described below.

Test environment: http://test-projectname-company.bizagi.com

Production environment: http://projectname-company.bizagi.com


If the customer uses the mobile application the project's URL should be updated as well, using the same URLs for desktop access.


It is necessary to inform this change to the customer's organization with due time.


Case links

Your SMTP configuration needs to be changed to adapt to Bizagi PaaS setup. The Cloud Operations team will send you instructions to adjust the SMTP server information in all your environments.


Users and access rights

Moving to Bizagi PaaS will require the creation and delegation of users to be administrators of the subscription. These users will be able to monitor resources, and make the actual deployments to the Testing and Production environments.

All end users should have their own unique email. Email duplicates are not supported in Bizagi PaaS.

Users and groups will be exactly the same as in on premise application. No additional configuration is required.

It is highly recommended that customer's administrators take the cloud administration training course, prior to the migration to Bizagi PaaS.


About performance considerations

For those features where there are performance considerations, you will need to take into account certain aspects relevant to your network communications, application design, testing and tuning overall. This applies when connecting to on-premises systems via a VPN.

Given the nature of a cloud-based service where the communication from your premises to the cloud inherently depends upon factors which are beyond Bizagi PaaS' control (such as a higher latency in data transmission, fluctuations, interference and congestion affecting the speed of the channel, the quality of the networks used during transmission, etc), you will need to make sure that the use you give to certain features is appropriate for the specific requirements of your applications.


About service-based integration

Recall that it is strongly recommended to rely on a service-oriented architecture in order to make the most of your Bizagi PaaS implementation.

The VPN alternative is strictly optional and furthermore, it is not the recommended option.

Through a best practice such as a service-based integration, you achieve greater maintainability and scalability among others, and also promote a better system architecture over the one entailed in point-to-point communications.