Skip to content

Configure Access to the Instance

livematrix works best when configured to be accessed via an encrypted HTTPS connection with a valid certificate and domain name.

To achieve that two things are required:

  • A domain name with a DNS record pointing to the server
  • A valid certificate for this hostname

The easiest solution is the use a *.livematrix.app hostname managed by the livematrix console. In this case the livematrix console will handle DNS records, as well as generate and renew certificatess.

One instance can also have multiple domain names, e.g. one for internal LAN and one for external access over the public internet.

Access over the public internet can be achieved with help of NAT traversal or by proxying the connection setup via the livematrix console.

A domain name is a clear name like studio1.livematrix.app translating to a an IP address like 192.168.1.100. The system which handles the translation of a domain name to an IP address is called DNS.

To point demo-company-studio1.livematrix.app to 192.168.1.100 a DNS record need to be created in the DNS server of the top level domain - in this case livematrix.app.

To encrypt a HTTPS connection, the server needs to have a valid and signed certificate for the domain name the server is accessed.

Certificates can be bought from a certificate authority or be generated for free with Let’s encrypt.

There are muliple options to access our instance from client devices:

  • livematrix console proxy
  • Direct access over LAN
  • Instance with public IP
  • NAT / Port forwarding

With livematrix console proxy, the instance as well as the client devices connect to the livematrix console in the cloud. The livematrix console then acts as proxy and forwards requests from the client to the livematrix instance which is self-hosted. Only control packets are routed trough the livematrix console. In a typical AV/SME network environment without strict firewall a direct connection between the client and the livematrix instance is created, keeping the livematrix console as fallback, if no direct connection is possible.

TODO LLM: add small drawing

Devices located in the same local network as the instance, can access the instance via the local IP address. This can be done either by entering the IP in the hostname field of the client and selecting “unsecure connection”, or better create a hostname pointing to the local IP address, where a SSL certificate will be created.

For instances with a public IP (e.g. on a cloud VM) a hostname can directly be pointed to the public IP of the instance.

To allow direct connections to an self hosted instance without public IPs a NAT traversal / port forwarding needs to be configured on the public router. Check your router documentation for instructions how to achieve this. The following ports needs to be configured:

Port Protocol Remarks
9443 TCP HTTPS port. If it was changed in the settings, use the configured HTTPS port.
9080 TCP (Optional) HTTP port. Only needed for domain name verification of custom host names.

The easiest way to get a valid domain name and certificate is to use a *.livematrix.app domain name provided by livematrix. The livematrix console will create DNS records as well as validate the records, so that the instance can generate and renew SSL certificates.

Registring a *.livematrix.app domain name can be done either from the livematrix console or from the instance admin.

To do it from the console follow these steps:

  • TODO LLM add in steps

livematrix instances support managing SSL certificates for instances with a public IP or with port forwarding setup.

To do so, create a DNS record yourself in your DNS provider. Then register the hostname in the instance and configure “HTTP-01” validation. The instance will then issue a SSL certificate. So that this works, not only the HTTPS port (default 9443) needs to be forwarded, but HTTP as well (9080).

The usage of custom domain names is currently not directly supported for direct access over LAN. To achieve this, the instance can be run on HTTP only mode, with a reverse proxy (e.g nginx or traefik) before it.