Skip to content

OpenVidu Single Node COMMUNITY installation: AWS#

AWS

This section contains instructions for deploying a production-ready OpenVidu Single Node COMMUNITY deployment on AWS. The deployed services are the same as in the On Premises Single Node installation, but the process is automated through AWS CloudFormation.

First of all, import the template in the AWS CloudFormation console. You can click the following button...

Deploy to AWS

...or access your AWS CloudFormation console and manually set this S3 URL in the Specify template section:

https://s3.eu-west-1.amazonaws.com/get.openvidu.io/community/singlenode/latest/aws/cf-openvidu-singlenode.yaml

Info

If you want to deploy a specific version of OpenVidu Single Node, replace latest with the version you want to deploy. For example, to deploy version 3.6.0, use the following URL:

https://s3.eu-west-1.amazonaws.com/get.openvidu.io/community/singlenode/3.6.0/aws/cf-openvidu-singlenode.yaml

This is what the deployment architecture looks like:

OpenVidu Single Node AWS Architecture
OpenVidu Single Node AWS Architecture

CloudFormation Parameters#

Depending on your needs, you need to fill the following CloudFormation parameters:

Domain and SSL Certificate Configuration#

There are three possible scenarios for this section:

If you don't have a Domain Name and want to quickly test OpenVidu on AWS, you can use this option by selecting CertificateType as letsencrypt and keeping the rest of the parameters empty.

It will deploy OpenVidu with a Let's Encrypt certificate generated using sslip.io based on the public IP created for the deployment.

sslip.io rate limiting

sslip.io is currently experiencing Let's Encrypt rate limiting issues, which may prevent SSL certificates from being generated. It is recommended to use your own domain name. Check this community thread for troubleshooting and updates.

Let's Encrypt certificates

For a production environment, it is highly recommended to use this option. It allows you to deploy OpenVidu on AWS with a valid Let's Encrypt certificate for your Fully Qualified Domain Name (FQDN).

Create an Elastic IP beforehand and ensure your Domain Name points to it.

Let's Encrypt certificates

You can specify the DomainName with your FQDN and optionally the PublicElasticIP with the Elastic IP that the domain points to.

Opt for this method if you possess your own certificate for an existing FQDN. It enables you to deploy OpenVidu on AWS using your certificates.

Ensure you have a Fully Qualified Domain Name (FQDN) pointing to a previously created Elastic IP.

You also need a temporary HTTP server hosting your private and public certificate under a specific URL. These URLs are required so the instance can download and install your certificates.

The configured parameters would look like this:

Custom certificates

Specify the certificate files in base64 in OwnPublicCertificate and OwnPrivateCertificate. The DomainName and PublicElasticIP parameters are mandatory.

Certificates need to be in PEM format and base64 encoded. You can encode them using the following command in a terminal where fullchain.pem is your public certificate and privkey.pem is your private certificate:

base64 -w 0 fullchain.pem # OwnPublicCertificate
base64 -w 0 privkey.pem # OwnPrivateCertificate

This option is useful for development and testing purposes. It allows you to deploy OpenVidu on AWS with an autogenerated self-signed certificate. This way, you can quickly set up a secure connection without the need to obtain a certificate from a trusted Certificate Authority (CA).

However, this convenience comes with the caveat that users will need to manually accept the certificate in their web browsers. Please be aware that this configuration is solely for developmental and testing purposes and is not suitable for a production environment.

These are the parameters needed in this section to use self-signed certificates:

Self-signed certificates

You can optionally specify a DomainName. If no domain name is provided, sslip.io{:target="blank"} will be used to generate a domain based on the public IP. Just select the CertificateType as _self-signed.

OpenVidu Meet Credentials#

Configure the initial credentials for accessing OpenVidu Meet:

Parameters in this section look like this:

OpenVidu Meet credentials

  • InitialMeetAdminPassword: Initial password for the "admin" user in OpenVidu Meet. If not provided, a random password will be generated and stored in the AWS Secret Manager.
  • InitialMeetApiKey: Initial API key for OpenVidu Meet. If not provided, no API key will be set and the user can configure it later from the Meet Console.

Both parameters are optional. If you don't specify them, you can retrieve the generated credentials from the AWS Secret Manager after deployment.

EC2 Instance Configuration#

You need to specify some properties for the EC2 instance that will be created.

Parameters in this section look like this:

EC2 Instance configuration

Simply select the type of instance you want to deploy at InstanceType, the SSH key you want to use to access the machine at KeyName, and the Ubuntu distribution you want to use at OperatingSystem.

By default, the parameter OperatingSystem is configured to use the latest LTS Ubuntu AMI, so ideally you don’t need to modify this.

S3 bucket for application data and recordings#

You can specify an S3 bucket to store the recordings and application data. If this parameter is not specified, a new S3 bucket will be created by the CloudFormation stack.

Parameters in this section look like this:

S3 bucket for application data and recordings

You can specify an existing S3 bucket or leave it empty to create a new one.

(Optional) Additional flags#

Additional optional flags to pass to the OpenVidu installer (comma-separated, e.g., --flag1=value, --flag2).

Parameters in this section look like this:

OpenVidu Meet credentials

For example (optional), you can use --force-utc-timezone to force UTC as the timezone for OpenVidu. By default, OpenVidu uses the timezone configured on the host machine where it is installed. In general, UTC is recommended, and AWS EC2 instances already default to UTC, so this flag is not usually necessary.

Deploying the stack#

When you are ready with your CloudFormation parameters, just click on "Next", specify in "Stack failure options" the option "Preserve successfully provisioned resources" to be able to troubleshoot the deployment in case of error, click on "Next" again, and finally "Submit".

When everything is ready, you will see the following links in the "Outputs" section of CloudFormation:

CloudFormation Outputs

Configure your application to use the deployment#

The Output Key ServicesAndCredentials of the previous section points to an AWS Secret Manager secret that contains all URLs and credentials to access the services deployed. You can access the secret by clicking on the link in the Output Value column.

Then, click on Retrieve secret value to get the JSON with all the information.

To use your OpenVidu deployment, check the values of the JSON secret. All access credentials of all services are defined in this object. The most relevant ones are:

OpenVidu Meet:

  • OPENVIDU_URL: The URL to access OpenVidu Meet, which is always https://yourdomain.example.io/
  • MEET_INITIAL_ADMIN_USER: User to access OpenVidu Meet Console. It is always admin.
  • MEET_INITIAL_ADMIN_PASSWORD: Password to access OpenVidu Meet Console.
  • MEET_INITIAL_API_KEY: API key to use OpenVidu Meet Embedded and OpenVidu Meet REST API.

Note

The MEET_INITIAL_ADMIN_USER, MEET_INITIAL_ADMIN_PASSWORD, and MEET_INITIAL_API_KEY values are initial settings that cannot be changed from AWS Secret Manager. They can only be changed from the Meet Console.

OpenVidu Platform:

  • LIVEKIT_URL: The URL to use LiveKit SDKs, which can be wss://yourdomain.example.io/ or https://yourdomain.example.io/ depending on the client library you are using.
  • LIVEKIT_API_KEY: API Key for LiveKit SDKs.
  • LIVEKIT_API_SECRET: API Secret for LiveKit SDKs.

Troubleshooting Initial CloudFormation Stack Creation#

If something goes wrong during the initial CloudFormation stack creation, your stack may reach the CREATE_FAILED status for multiple reasons. It could be due to a misconfiguration in the parameters, a lack of permissions, or a problem with the AWS services. When this happens, the following steps can help you troubleshoot the issue and identify what went wrong:

  1. While deploying the stack, make sure at "Stack failure options" you have selected the option "Preserve successfully provisioned resources" to be able to troubleshoot the deployment in case of an error.

    Disable Rollback on failure

  2. Check if the EC2 instance or instances are running. If they are not, check the CloudFormation events for any error messages.

  3. If the EC2 instance or instances are running, SSH into the instance and check the logs of the following files:

    • /var/log/cloud-init-output.log
    • /var/log/cloud-init.log

    These logs will give you more information about the CloudFormation stack creation process.

  4. If everything seems fine, check the status and the logs of the installed OpenVidu services.

Configuration and administration#

When your CloudFormation stack reaches the CREATE_COMPLETE status, your OpenVidu Single Node deployment is ready to use. You can check the Administration section to learn how to manage your deployment.