Below are tables of recommended instance types and the recommended maximum connected clients. For best performance Pritunl servers should be replicated across as many instances as possible handling as few clients as possible. Prices below are estimated costs for AWS and Google Cloud deployments.

Server Settings

For large deployments the Max Clients option should be set as low as possible (maximum concurrent clients/nodes in cluster). OpenVPN clients will choose a random server when connecting. Setting the max clients will prevent clients from flooding one node by dropping additional clients to trigger the clients to attempt to connect to a different node.

Creating Empty Hosts

When a user downloads the VPN profile it will contain a list of the hosts in a random order. Unless the official Pritunl client is used and clients have access to the web console port the configuration sync will not be available to update the configuration. For large deployments DNS names should always be used by setting the Public Address field in the host settings. In addition it is best to over estimate the number of hosts needed for the deployment so that client configurations will already contain the DNS names for hosts that will potentially be added in the future. This can be done by adding then removing multiple hosts to the cluster leaving the host entry in the hosts tab. To quickly create hosts with one server remove the /var/lib/pritunl.uuid file then restart the Pritunl service. After the empty hosts have been added fill in the Public Address field and attach the hosts to a server. Attaching empty hosts to a server will not causes issues as Pritunl will not attempt to run a server on an offline host.

To replace the empty hosts with real hosts when scaling delete the empty host and copy the Public Address field. Then attach the real host to the server and adjust the Replication Count.

When a VPN client attempts to connect to an empty or offline host it will fail and move on to the next host this increases the connection time. This can be avoided by adjusting the DNS entries for the empty hosts to the IP address of a running host until the DNS entry is used for a real host. Having multiple DNS entries pointing to the same host will not cause any issues.

remote server3.pritunl.net 16105 udp
remote server5.pritunl.net 16105 udp
remote server2.pritunl.net 16105 udp
remote server0.pritunl.net 16105 udp
remote server4.pritunl.net 16105 udp
remote server1.pritunl.net 16105 udp

Pritunl Recommended Instance Types

For Pritunl nodes instances with high CPU and high network bandwidth are recommend. On AWS c5 instance types have the best network performance. Google Cloud doesn't provide information on instance network performance. The max clients represents the maximum concurrent connections.

MongoDB Recommended Instance Types

For MongoDB instances with high memory are recommended. The max users represents the maximum number of users that can exists in Pritunl.

Example Deployments