The Virtual Appliance image is available in the Google, Amazon and Azure marketplaces. It is also available as a downloadable VMware OVA for ESX 6.0 and above. Below are the system requirements for hosting the virtual machine.

Supported Users Virtual Machine Requirements
1-100 2 vCPU, 4 GB RAM, 80 GB SSD
100 – 1,000 4 vCPU, 16 GB RAM, 200 GB SSD
1,000 – 10,000 8 vCPU, 32 GB RAM, 500 GB SSD

The Application can mount both Linux/NFS or Windows/SMB-CIFS file shares. However, to connect to Active Directory a Windows File Share must be used as the file source.

Any Windows file server that supports SMB 2.0 or 3.0 will work. Examples include Microsoft Windows 2012r2 and later servers, Isilon file servers, NetApp ONTAP file servers as well as cloud file servers including ONTAP FSX, Cloud Volumes ONTAP, and NetApp Cloud Volumes Service.

To run in the public cloud such as AWS, GCP or Azure:

  1. Launch the virtual appliance through your cloud portal within the same private network as your existing Active Directory and file server connection.
  2. Once launched, log-into the administration portal with your supplied username and password. The portal contains a web interface to configure your domain name and connect to your Active Directory service. In the portal you can also upload your SSL certificate. Finally you will mount your file servers that you would like to share to the application. The will index and sync the metadata of that server and be ready to securely share your file servers based on Active Directory permissions.
  3. Let your users know they can start accessing and sharing remotely at whatever domain you have setup for the server, such as  “”

Active Directory users that login with their corporate domain address will be able to browse only those shares for which they have existing active directory read or red/write access. This is enforced at the folder level. This is similar to access-based enumeration on traditional windows file servers. Corporate users will not be able to access mounted shares for which they are not given Active Directory permissions.

If external sharing is enabled, corporate active directory users will be able to invite guest users (non-active directory users) as collaborators. This can be very useful for example when collaborating on large projects where guest users can be given read-only or read-write permission to specific folders. This provides a secure, convenient alternative to FTP servers.

The is a “stateless” application that holds only copies of the metadata such as filenames and file paths of the shared folders. No file contents or user data is stored in the application. Thus re-deployment of the service in case of VM failure is quite simple. A reboot of the application based on a prior snapshot can be done in less than 4 minutes, supporting 99.99% availability.

For mission critical deployments, a kubernetes-based deployment leveraging multiple availability zones is an option. Please contact us for HA deployment support

The application requires a single public IP address, with all traffic running over port 443 to ensure all traffic is encrypted in TLS 1.2+ protocol meeting NIST and HIPAA recommendations.

Yes, all clients have a local cache feature. This enables continuous access to selected folders and files on mobile devices

Yes, SSO is achieved via Active Directory federation or via the included Okta integration. Active Directory passwords are never stored on the platform. All authentication traffic is encrypted and tunneled between the user client and your corporate Active Directory server.


Minimum 4 characters