Wire Deployment Options

Wire Deployment Overview

Wire allows its customers to choose from a variety of backend installations. For our turnkey deployment options, our current customers use Wire backend deployed on Wire infrastructure. But for compliance reasons, some of our customers can also choose Wire backend to be deployed on their cloud infrastructure or a private backend infrastructure of their choice. 

Sample Wire Backend Architecture

Deployment Scenarios

Wire has seen many different ways of deployment with its customers, and the following combinations are supported in various scenarios. 

If your needs vary from the above, please contact us sales@wire.com 

Backend Installation/Deployment

The Wire backend can be deployed “into the cloud” (IaaS / SaaS), on-premise with world-wide-web connectivity, or in an offline environment. The installation of Wire in an offline environment creates a new “island” of Wire users specific to that individual installment. The offline approach offers advantages in terms of privacy and security - however also creates complications in processes related to installation, updating the Wire software, and applying patches and updates to the software components used to support Wire (e.g., Kubernetes, Ubuntu/Debian, Docker, Cassandra, MinIO). 

Scaling Users & Conferencing Capabilities

Wire supports cloud, on-prem installations of its backend, the sample architecture diagram above is designed to support a couple of thousand messaging (chat, IM) users (however, the setup may vary for enterprises that have very different than usual traffic patterns). The guidelines below include scaling recommendations for supporting many conference call participants. Wire technical team can help you and your tech team with more information on your scaling needs, we can customize Wire’s backend system to meet your exact requirements.

Desktop & Mobile Apps Distribution

Wire has publicly available mobile apps on both Google Play Store and Apple App Store. With desktop applications that can be directly downloaded on Wire website. These apps are configured to work with the Wire Cloud infrastructure by default but can be reconfigured to work with your private Wire infrastructure. 

However, if you do have your own EMM/MDM, you can take control of your app distribution. For disabling or enabling certain features as part of the distribution, you can set these settings in the Wire Team Settings console. For Desktop and Android, Wire can also provide pre-compiled binaries that can be stored & downloaded from your own servers. 

Upgrades & Updates

Wire will provide update packages for customers which will bring their on-premises instance of Wire up-to-date with respect to features & functionality as well as security patches and bug fixes.  Wire will package and deliver updates to the Wire backend as part of a once per 6-months refresh cycle. However, the cadence of critical bug fixes, security vulnerability fixes is determined out of the 6-month cycle, with the shortest supportable deployment cycle. 

Other Deployment Considerations

• Calling Ports for On-Prem: For the highest reliability and quality Wire recommends allowing direct connectivity via UDP ports, but Wire also provides TURN servers to relay calls using UDP, TCP, or TLS. For more information - please go here. 
• Push Notifications for On-Prem: For all push notifications for custom clients on custom wire backend, you can choose from the following options:
• Option A: Proxy push notification through Wire AWS SNS architecture  
• Option B: Customer builds out their own AWS SNS architecture 
• Option C: no Push, customer only uses WebSockets (supported by desktop apps and Android apps, but not iOS apps)
• Conferencing Bandwidth -  Wire at a minimum recommends 1GbE networking for conferencing servers. To better understand bandwidth requirements for your specific needs, here are some guidelines for estimation or contact us.
• SSO/SCIM - Wire supports SSO/SCIM for easier user onboarding and adoption. For more detailed info, please go here for SCIM, here for SSO.

All guidelines in this document are looked at from a conferencing server point of view. For bandwidth requirements on the client-side, please go here (Note, FAQ entry needs an update for new conference calling). 

• 1 audio media stream is received per participant of a conference
• Up to 5 audio media streams are sent to every participant of a conference of more than 5 participants, for conferences with fewer participants, up to n audio media streams are sent to every participant (n equals the number of participants).
• 1 video media stream is received per participant of a conference
• Up to 9 video media streams are sent to every participant of a conference of 9 or more participants, for conferences with fewer participants, up to (n-1) video media streams are sent to every participant (n equals the number of participants).
• An audio media stream may use up to 50kbps.
• A video media stream may use up to 350kbps.
• Total bandwidth requirement depends on the number of concurrent conferences and the estimated number of participants per conference during peak times.