2025-11-19 10:39:53 +01:00
# ------------------------- variables -------------------------
# Variables used by the configuration
variable " projectId " {
2025-11-19 18:42:44 +01:00
description = " GCP project id where the resourw es will be created. "
2025-11-19 10:39:53 +01:00
type = string
}
variable " region " {
description = " GCP region where resources will be created. "
type = string
default = " europe-west2 "
}
variable " zone " {
description = " GCP zone that some resources will use. "
type = string
default = " europe-west2-b "
}
variable " stackName " {
description = " Stack name for OpenVidu deployment. "
type = string
}
variable " certificateType " {
2026-07-02 17:21:42 +02:00
description = " [selfsigned] Not recommended for production use. Just for testing purposes or development environments. You don't need a FQDN to use this option. [owncert] Valid for production environments. Use your own certificate. You need a FQDN to use this option. [letsencrypt] Valid for production environments. Can be used with or without a FQDN (if no FQDN is provided, the public IP will be used). "
2025-11-19 10:39:53 +01:00
type = string
default = " letsencrypt "
validation {
2025-11-19 18:42:44 +01:00
condition = contains ( [ " selfsigned " , " owncert " , " letsencrypt " ] , var . certificateType )
error_message = " certificateType must be one of: selfsigned, owncert, letsencrypt "
}
}
variable " publicIpAddress " {
description = " Previously created Public IP address for the OpenVidu Deployment. Blank will generate a public IP. "
type = string
default = " "
validation {
condition = can ( regex ( " ^ $ |^([01]? \\ d{1,2}|2[0-4] \\ d|25[0-5]) \\ .([01]? \\ d{1,2}|2[0-4] \\ d|25[0-5]) \\ .([01]? \\ d{1,2}|2[0-4] \\ d|25[0-5]) \\ .([01]? \\ d{1,2}|2[0-4] \\ d|25[0-5]) $ " , var . publicIpAddress ) )
error_message = " The Public Elastic IP does not have a valid IPv4 format "
2025-11-19 10:39:53 +01:00
}
}
variable " domainName " {
description = " Domain name for the OpenVidu Deployment. "
type = string
default = " "
validation {
condition = can ( regex ( " ^ $ |^(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])? \\ .)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9] $ " , var . domainName ) )
2025-11-19 18:42:44 +01:00
error_message = " The domain name does not have a valid domain name format "
2025-11-19 10:39:53 +01:00
}
}
variable " ownPublicCertificate " {
2025-12-23 22:11:16 +01:00
description = " If certificate type is 'owncert', this parameter will be used to specify the public certificate in base64 format "
2025-11-19 10:39:53 +01:00
type = string
default = " "
}
variable " ownPrivateCertificate " {
2025-12-23 22:11:16 +01:00
description = " If certificate type is 'owncert', this parameter will be used to specify the private certificate in base64 format "
2025-11-19 10:39:53 +01:00
type = string
default = " "
}
variable " initialMeetAdminPassword " {
description = " Initial password for the 'admin' user in OpenVidu Meet. If not provided, a random password will be generated. "
type = string
default = " "
validation {
2025-11-19 18:42:44 +01:00
condition = can ( regex ( " ^[A-Za-z0-9_-]* $ " , var . initialMeetAdminPassword ) )
error_message = " Must contain only alphanumeric characters (A-Z, a-z, 0-9). Leave empty to generate a random password. "
2025-11-19 10:39:53 +01:00
}
}
variable " initialMeetApiKey " {
description = " Initial API key for OpenVidu Meet. If not provided, no API key will be set and the user can set it later from Meet Console. "
type = string
default = " "
validation {
2025-11-19 18:42:44 +01:00
condition = can ( regex ( " ^[A-Za-z0-9_-]* $ " , var . initialMeetApiKey ) )
error_message = " Must contain only alphanumeric characters (A-Z, a-z, 0-9). Leave empty to not set an initial API key. "
2025-11-19 10:39:53 +01:00
}
}
openvidu-deployment: the same defaults and parameter names on every cloud
The templates of the five clouds had drifted apart. On AWS, Azure and Google
Cloud:
- 200 GB disk for the single node and the Master Nodes, the default where
the template sets its size: Azure and Google Cloud raise it from 100 GB,
as do the AWS High Availability Master Nodes. On Google Cloud an existing
single node or Elastic Master Node keeps its disk when the template is
applied again.
- Google Cloud boots the latest Ubuntu 24.04 (the ubuntu-2404-lts image
family) instead of an image pinned in December 2024; an existing single
node or Master Node is not recreated when a newer image is published.
- Same parameter names on every Terraform and Bicep template, with the old
names deprecated but still honored (they win when set): rtcEngine on the
Google Cloud single node, whose documented name was not applied, and
masterNodeInstanceType on Google Cloud High Availability.
- Azure no longer opens port 9000 (MinIO) on the single node and Elastic:
MinIO does not run there, and the other clouds closed it in 3.9.0.
- The Media Nodes install with the same arguments on every cloud: Azure
passes --master-node-private-ip and no longer --enabled-modules, and the
user-data names the variable MASTER_NODE_PRIVATE_IP everywhere.
The CHANGELOG also lists the DigitalOcean and Oracle Cloud changes made in
their repositories (v2compatibility by default, masterNodeInstanceType,
the Oracle single node size and disk, rtcEngine).
2026-10-27 19:11:15 +01:00
variable " masterNodeInstanceType " {
2025-11-19 18:42:44 +01:00
description = " Specifies the GCE machine type for your OpenVidu Master Node "
2025-11-19 10:39:53 +01:00
type = string
2026-02-05 18:42:34 +01:00
default = " e2-standard-4 "
2025-11-19 10:39:53 +01:00
}
openvidu-deployment: the same defaults and parameter names on every cloud
The templates of the five clouds had drifted apart. On AWS, Azure and Google
Cloud:
- 200 GB disk for the single node and the Master Nodes, the default where
the template sets its size: Azure and Google Cloud raise it from 100 GB,
as do the AWS High Availability Master Nodes. On Google Cloud an existing
single node or Elastic Master Node keeps its disk when the template is
applied again.
- Google Cloud boots the latest Ubuntu 24.04 (the ubuntu-2404-lts image
family) instead of an image pinned in December 2024; an existing single
node or Master Node is not recreated when a newer image is published.
- Same parameter names on every Terraform and Bicep template, with the old
names deprecated but still honored (they win when set): rtcEngine on the
Google Cloud single node, whose documented name was not applied, and
masterNodeInstanceType on Google Cloud High Availability.
- Azure no longer opens port 9000 (MinIO) on the single node and Elastic:
MinIO does not run there, and the other clouds closed it in 3.9.0.
- The Media Nodes install with the same arguments on every cloud: Azure
passes --master-node-private-ip and no longer --enabled-modules, and the
user-data names the variable MASTER_NODE_PRIVATE_IP everywhere.
The CHANGELOG also lists the DigitalOcean and Oracle Cloud changes made in
their repositories (v2compatibility by default, masterNodeInstanceType,
the Oracle single node size and disk, rtcEngine).
2026-10-27 19:11:15 +01:00
variable " masterNodesInstanceType " {
description = " Deprecated: replaced by masterNodeInstanceType. Kept for backward compatibility; if set to a non-empty value it still takes precedence over masterNodeInstanceType. "
type = string
default = " "
}
2025-11-19 10:39:53 +01:00
variable " masterNodesDiskSize " {
description = " Size of the disk in GB for master nodes "
type = number
openvidu-deployment: the same defaults and parameter names on every cloud
The templates of the five clouds had drifted apart. On AWS, Azure and Google
Cloud:
- 200 GB disk for the single node and the Master Nodes, the default where
the template sets its size: Azure and Google Cloud raise it from 100 GB,
as do the AWS High Availability Master Nodes. On Google Cloud an existing
single node or Elastic Master Node keeps its disk when the template is
applied again.
- Google Cloud boots the latest Ubuntu 24.04 (the ubuntu-2404-lts image
family) instead of an image pinned in December 2024; an existing single
node or Master Node is not recreated when a newer image is published.
- Same parameter names on every Terraform and Bicep template, with the old
names deprecated but still honored (they win when set): rtcEngine on the
Google Cloud single node, whose documented name was not applied, and
masterNodeInstanceType on Google Cloud High Availability.
- Azure no longer opens port 9000 (MinIO) on the single node and Elastic:
MinIO does not run there, and the other clouds closed it in 3.9.0.
- The Media Nodes install with the same arguments on every cloud: Azure
passes --master-node-private-ip and no longer --enabled-modules, and the
user-data names the variable MASTER_NODE_PRIVATE_IP everywhere.
The CHANGELOG also lists the DigitalOcean and Oracle Cloud changes made in
their repositories (v2compatibility by default, masterNodeInstanceType,
the Oracle single node size and disk, rtcEngine).
2026-10-27 19:11:15 +01:00
default = 200
2025-11-19 10:39:53 +01:00
validation {
2025-11-19 18:42:44 +01:00
condition = var . masterNodesDiskSize > = 70
error_message = " masterNodesDiskSize must be at least 70 GB. "
2025-11-19 10:39:53 +01:00
}
}
variable " mediaNodeInstanceType " {
description = " Specifies the GCE machine type for your OpenVidu Media Nodes "
type = string
2026-02-05 18:42:34 +01:00
default = " e2-standard-4 "
2025-11-19 10:39:53 +01:00
}
variable " initialNumberOfMediaNodes " {
openvidu-deployment: a fixed number of Media Nodes on AWS, Azure and Google Cloud
Elastic and High Availability deployments on AWS, Azure and Google Cloud can
run a fixed number of Media Nodes, as DigitalOcean and Oracle Cloud already
could, with the same parameter: FixedNumberOfMediaNodes on AWS,
fixedNumberOfMediaNodes on the other clouds. 0, the default, keeps
autoscaling; a value greater than 0 runs exactly that many Media Nodes and
ignores the initial, minimum, maximum and target CPU parameters. A redeploy
with another value changes the number or switches mode, both ways.
- AWS: the Auto Scaling Group's min, max and desired are the fixed number
and the scaling policy is not created. A Media Node the number no longer
needs is drained by the existing lifecycle hook, as in a scale-in.
- Google Cloud: no autoscaler; the scale-in function, which now runs in both
modes, keeps the managed instance group at the fixed number, abandoning an
extra Media Node so it drains and deletes itself, or resizing the group up.
The group's target size is set at creation only, the function's source is
named by its hash so a code change redeploys it, and `moved` blocks keep
existing autoscalers when the template is applied again.
- Azure: the autoscale setting stays, pinned to the fixed number (minimum =
maximum = default). Azure refuses an autoscale minimum below the Media
Nodes running, which protect themselves from scale-in, so lowering it is a
manual drain first (manual scale, then stop_media_node.sh on each extra
Media Node) and then the redeploy; the CHANGELOG and the documentation
describe it. The portal's form gets the field.
Verified live with ov-cloud-tester's sc-fixed-media-nodes scenario on
Elastic (Google Cloud, AWS and Azure): deploy with 2, lower to 1 (the Media
Node removed served its Room through a 1200 s hold and left once it was
closed), back to autoscaling with no Media Node added or removed.
2026-10-27 19:09:59 +01:00
description = " Number of initial media nodes to deploy. Ignored when fixedNumberOfMediaNodes > 0 "
2025-11-19 10:39:53 +01:00
type = number
default = 1
}
variable " minNumberOfMediaNodes " {
openvidu-deployment: a fixed number of Media Nodes on AWS, Azure and Google Cloud
Elastic and High Availability deployments on AWS, Azure and Google Cloud can
run a fixed number of Media Nodes, as DigitalOcean and Oracle Cloud already
could, with the same parameter: FixedNumberOfMediaNodes on AWS,
fixedNumberOfMediaNodes on the other clouds. 0, the default, keeps
autoscaling; a value greater than 0 runs exactly that many Media Nodes and
ignores the initial, minimum, maximum and target CPU parameters. A redeploy
with another value changes the number or switches mode, both ways.
- AWS: the Auto Scaling Group's min, max and desired are the fixed number
and the scaling policy is not created. A Media Node the number no longer
needs is drained by the existing lifecycle hook, as in a scale-in.
- Google Cloud: no autoscaler; the scale-in function, which now runs in both
modes, keeps the managed instance group at the fixed number, abandoning an
extra Media Node so it drains and deletes itself, or resizing the group up.
The group's target size is set at creation only, the function's source is
named by its hash so a code change redeploys it, and `moved` blocks keep
existing autoscalers when the template is applied again.
- Azure: the autoscale setting stays, pinned to the fixed number (minimum =
maximum = default). Azure refuses an autoscale minimum below the Media
Nodes running, which protect themselves from scale-in, so lowering it is a
manual drain first (manual scale, then stop_media_node.sh on each extra
Media Node) and then the redeploy; the CHANGELOG and the documentation
describe it. The portal's form gets the field.
Verified live with ov-cloud-tester's sc-fixed-media-nodes scenario on
Elastic (Google Cloud, AWS and Azure): deploy with 2, lower to 1 (the Media
Node removed served its Room through a 1200 s hold and left once it was
closed), back to autoscaling with no Media Node added or removed.
2026-10-27 19:09:59 +01:00
description = " Minimum number of media nodes to deploy. Ignored when fixedNumberOfMediaNodes > 0 "
2025-11-19 10:39:53 +01:00
type = number
default = 1
}
variable " maxNumberOfMediaNodes " {
openvidu-deployment: a fixed number of Media Nodes on AWS, Azure and Google Cloud
Elastic and High Availability deployments on AWS, Azure and Google Cloud can
run a fixed number of Media Nodes, as DigitalOcean and Oracle Cloud already
could, with the same parameter: FixedNumberOfMediaNodes on AWS,
fixedNumberOfMediaNodes on the other clouds. 0, the default, keeps
autoscaling; a value greater than 0 runs exactly that many Media Nodes and
ignores the initial, minimum, maximum and target CPU parameters. A redeploy
with another value changes the number or switches mode, both ways.
- AWS: the Auto Scaling Group's min, max and desired are the fixed number
and the scaling policy is not created. A Media Node the number no longer
needs is drained by the existing lifecycle hook, as in a scale-in.
- Google Cloud: no autoscaler; the scale-in function, which now runs in both
modes, keeps the managed instance group at the fixed number, abandoning an
extra Media Node so it drains and deletes itself, or resizing the group up.
The group's target size is set at creation only, the function's source is
named by its hash so a code change redeploys it, and `moved` blocks keep
existing autoscalers when the template is applied again.
- Azure: the autoscale setting stays, pinned to the fixed number (minimum =
maximum = default). Azure refuses an autoscale minimum below the Media
Nodes running, which protect themselves from scale-in, so lowering it is a
manual drain first (manual scale, then stop_media_node.sh on each extra
Media Node) and then the redeploy; the CHANGELOG and the documentation
describe it. The portal's form gets the field.
Verified live with ov-cloud-tester's sc-fixed-media-nodes scenario on
Elastic (Google Cloud, AWS and Azure): deploy with 2, lower to 1 (the Media
Node removed served its Room through a 1200 s hold and left once it was
closed), back to autoscaling with no Media Node added or removed.
2026-10-27 19:09:59 +01:00
description = " Maximum number of media nodes to deploy. Ignored when fixedNumberOfMediaNodes > 0 "
2025-11-19 10:39:53 +01:00
type = number
2026-01-27 16:37:33 +01:00
default = 5
2025-11-19 10:39:53 +01:00
}
variable " scaleTargetCPU " {
openvidu-deployment: a fixed number of Media Nodes on AWS, Azure and Google Cloud
Elastic and High Availability deployments on AWS, Azure and Google Cloud can
run a fixed number of Media Nodes, as DigitalOcean and Oracle Cloud already
could, with the same parameter: FixedNumberOfMediaNodes on AWS,
fixedNumberOfMediaNodes on the other clouds. 0, the default, keeps
autoscaling; a value greater than 0 runs exactly that many Media Nodes and
ignores the initial, minimum, maximum and target CPU parameters. A redeploy
with another value changes the number or switches mode, both ways.
- AWS: the Auto Scaling Group's min, max and desired are the fixed number
and the scaling policy is not created. A Media Node the number no longer
needs is drained by the existing lifecycle hook, as in a scale-in.
- Google Cloud: no autoscaler; the scale-in function, which now runs in both
modes, keeps the managed instance group at the fixed number, abandoning an
extra Media Node so it drains and deletes itself, or resizing the group up.
The group's target size is set at creation only, the function's source is
named by its hash so a code change redeploys it, and `moved` blocks keep
existing autoscalers when the template is applied again.
- Azure: the autoscale setting stays, pinned to the fixed number (minimum =
maximum = default). Azure refuses an autoscale minimum below the Media
Nodes running, which protect themselves from scale-in, so lowering it is a
manual drain first (manual scale, then stop_media_node.sh on each extra
Media Node) and then the redeploy; the CHANGELOG and the documentation
describe it. The portal's form gets the field.
Verified live with ov-cloud-tester's sc-fixed-media-nodes scenario on
Elastic (Google Cloud, AWS and Azure): deploy with 2, lower to 1 (the Media
Node removed served its Room through a 1200 s hold and left once it was
closed), back to autoscaling with no Media Node added or removed.
2026-10-27 19:09:59 +01:00
description = " Target CPU percentage to scale up or down. Ignored when fixedNumberOfMediaNodes > 0 "
2025-11-19 10:39:53 +01:00
type = number
default = 50
}
openvidu-deployment: a fixed number of Media Nodes on AWS, Azure and Google Cloud
Elastic and High Availability deployments on AWS, Azure and Google Cloud can
run a fixed number of Media Nodes, as DigitalOcean and Oracle Cloud already
could, with the same parameter: FixedNumberOfMediaNodes on AWS,
fixedNumberOfMediaNodes on the other clouds. 0, the default, keeps
autoscaling; a value greater than 0 runs exactly that many Media Nodes and
ignores the initial, minimum, maximum and target CPU parameters. A redeploy
with another value changes the number or switches mode, both ways.
- AWS: the Auto Scaling Group's min, max and desired are the fixed number
and the scaling policy is not created. A Media Node the number no longer
needs is drained by the existing lifecycle hook, as in a scale-in.
- Google Cloud: no autoscaler; the scale-in function, which now runs in both
modes, keeps the managed instance group at the fixed number, abandoning an
extra Media Node so it drains and deletes itself, or resizing the group up.
The group's target size is set at creation only, the function's source is
named by its hash so a code change redeploys it, and `moved` blocks keep
existing autoscalers when the template is applied again.
- Azure: the autoscale setting stays, pinned to the fixed number (minimum =
maximum = default). Azure refuses an autoscale minimum below the Media
Nodes running, which protect themselves from scale-in, so lowering it is a
manual drain first (manual scale, then stop_media_node.sh on each extra
Media Node) and then the redeploy; the CHANGELOG and the documentation
describe it. The portal's form gets the field.
Verified live with ov-cloud-tester's sc-fixed-media-nodes scenario on
Elastic (Google Cloud, AWS and Azure): deploy with 2, lower to 1 (the Media
Node removed served its Room through a 1200 s hold and left once it was
closed), back to autoscaling with no Media Node added or removed.
2026-10-27 19:09:59 +01:00
variable " fixedNumberOfMediaNodes " {
description = " If > 0, deploys a fixed number of media nodes with no autoscaling (initialNumberOfMediaNodes, minNumberOfMediaNodes, maxNumberOfMediaNodes and scaleTargetCPU are ignored). If 0 (default), the deployment is elastic and autoscaling is enabled "
type = number
default = 0
validation {
condition = var . fixedNumberOfMediaNodes > = 0 && floor ( var . fixedNumberOfMediaNodes ) = = var . fixedNumberOfMediaNodes
error_message = " fixedNumberOfMediaNodes must be a whole number >= 0. "
}
}
2025-11-19 10:39:53 +01:00
variable " GCSAppDataBucketName " {
description = " Name of the GCS bucket to store application data and recordings. If empty, a bucket will be created "
type = string
default = " "
}
variable " GCSClusterDataBucketName " {
description = " Name of the GCS bucket to store cluster data. If empty, a bucket will be created "
type = string
default = " "
}
variable " openviduLicense " {
description = " Visit https://openvidu.io/account "
type = string
sensitive = true
}
variable " rtcEngine " {
description = " RTCEngine media engine to use "
type = string
2026-09-29 14:56:16 +02:00
default = " mediasoup "
2025-11-19 10:39:53 +01:00
validation {
2025-11-19 18:42:44 +01:00
condition = contains ( [ " pion " , " mediasoup " ] , var . rtcEngine )
error_message = " rtcEngine must be one of: pion, mediasoup "
2025-11-19 10:39:53 +01:00
}
}
variable " additionalInstallFlags " {
description = " Additional optional flags to pass to the OpenVidu installer (comma-separated, e.g.,'--flag1=value, --flag2'). "
type = string
default = " "
validation {
2025-11-19 18:42:44 +01:00
condition = can ( regex ( " ^[A-Za-z0-9, =_. \\ -]* $ " , var . additionalInstallFlags ) )
error_message = " Must be a comma-separated list of flags (for example, --flag=value, --bool-flag). "
2025-11-19 10:39:53 +01:00
}
}