Licensing: Main concepts
Learn about the main concepts about licensing on Digibee Integration Platform
Last updated
Was this helpful?
Learn about the main concepts about licensing on Digibee Integration Platform
Last updated
Was this helpful?
Was this helpful?
Understanding how licensing works is essential to getting the most out of the Digibee Integration Platform. This document introduces the main licensing concepts, to help you manage usage more effectively and ensure your organization remains compliant with licensing agreements.
Digibee currently offers three licensing models:
Consumption is based on the number of deployed pipelines, with no distinction between environments.
This model is no longer available for new purchases but is still fully supported for existing customers.
Consumption is based on RTUs, with separate RTU packages for Prod and Test environments.
This allows better control over resource usage per environment.
Consumption is measured using multiple metrics, including:
GB-seconds (GB-s)
Egress traffic
Pipeline executions
To choose the most suitable license model for your business and correctly monitor usage, it’s important to understand some key concepts used in the Digibee Integration Platform.
This applies to Pipeline-Based, Subscription-Based, and Consumption-Based models.
There is no limit to how many pipelines you can create in the Digibee Integration Platform. Only deployed pipelines (whether in Test or Prod environments) are counted toward resource usage. The more deployed pipelines you have, the higher your consumption.
Different major versions of the same pipeline are considered unique pipelines. Each version may consume a different amount of resources.
This applies to Pipeline-Based and Subscription-Based models.
RTU is the unit of measurement for resource consumption when deploying a pipeline. Each deployment consumes a specific number of RTUs depending on the pipeline size.
RTUs support both vertical and horizontal scaling of integrations:
Vertical scaling: Consumption varies based on the size of the pipeline.
Horizontal scaling: Each additional replica consumes the same number of RTUs as the original deployment.
Each RTU is delivered with the underlying infrastructure for its operation. The following table provides a reference for pipeline size and RTU consumption:
Pipeline size
RTU consumption
Small
1
Medium
2
Large
4
SaaS (Software as a Service) is a software delivery model in which the software is hosted in the cloud and accessed over the internet. The Digibee Integration Platform offers two hosting options:
Multi-tenant (Public SaaS): All accounts share the same platform and features, but each account belongs to a unique realm. No data is shared between realms. All access is governed by Digibee’s security system.
Single-tenant (Dedicated SaaS): Only your company and Digibee have access to a dedicated environment. You can build and deploy pipelines with the same set of features and connectors available on the multi-tenant model.
To learn more, visit the Platform Hosting documentation.
Platform usage quotas are technical limits applied to each realm to maintain platform stability. These limits are based on average usage patterns and include:
Deployment size and number of replicas (CPU and memory)
Egress traffic rate
Number of produced/consumed messages
Messages retained for processing
Log retention
VPN connections
Storage usage (Object Store, Digibee Storage, and Relationship Data)
Represents the total memory usage of a pipeline replica over time. It’s calculated by multiplying the memory allocated (in GB) by the duration the instance is running (in seconds).
Overage happens when you exceed your allocated credit limit. Pipelines will continue running, but any usage beyond your original commitment is billed separately at an overage rate applied to all consumption metrics.
Represents the number of times a pipeline is executed.
Refers to all data that exits the Digibee Integration Platform — whether to the public internet, other clouds, or on-premise networks.
Autoscaling automatically adjusts the number of active replicas based on the workload. Replicas are created or removed depending on the number of messages in the queue (invocations).