LiquidFiles Documentation
LiquidFiles Documentation

Planning the deployment

LiquidFiles is server software, like a web or mail server, and needs to be installed somewhere where it can run 24x7 to function properly.

A typical production installation of LiquidFiles looks like this:

The LiquidFiles appliance is typically deployed in a DMZ, next to your mail and web server. For normal usage, it will also need to be reachable from the Internet.

For test installations, you can deploy LiquidFiles on pretty much any system, including running on VMware or similar virtualization platforms on your Mac or PC. Please beware though that similarly to a web server, LiquidFiles needs to be running and connected for anyone to be able to download any files from it.

Selecting platform

LiquidFiles is a virtual appliance, meaning that it will come ready with it's own operating system, all the required components and the application itself. It is not possible to install LiquidFiles on an already running and installed system. It needs to be installed as a separate server. It aims to be as flexible as possible, and you have three basic installation options.

Physical Server

Just like any server, you can use the downloadable ISO image to burn a CD and install on pretty much any available physical server.

This installation option is likely to provide the maximum performance as there's no other resources competing with the available resources (CPU, memory and disks).

All data is kept within your environment for maximum security and performance.

Virtual Server

This is the most popular installation option. Using your existing VMware, Microsoft Hyper-V, Citrix Xen or similar virtual platform, you can install LiquidFiles as another virtual server.

While the performance is not going to be as great as a dedicated physical server, in the overwhelmingly majority of cases it's going to be adequate performance and you will get the typical virtual server benefits of sharing physical server space, power, cooling, etc.

All data is kept within your environment for maximum security and performance.

Private Cloud

If you want to use the benefits of running LiquidFiles in the Cloud, you can either deploy LiquidFiles in any of the available Amazon AWS or Microsoft Azure data centres, or deploy in any other cloud server provider that offers you to run your own virtual system where you can install your own system using an ISO image.

Performance and Security is going to be similar to your other virtual servers in your chosen cloud provider.

Network Connections

The following table outlines the network connections that the LiquidFiles requires to operate (IP addresses assumed to be as in the network diagram above).

Protocol / Function source destination port description
http(s) any 80 & 443 http and https is allowed from anywhere. This is how all files are uploaded and downloaded and all normal user interaction is via http or https.
DNS DNS server 53 (UDP) The appliance needs DNS to function properly.
email any / email relay server 25 The appliance needs to send emails, either via an email relay server or directly to the Internet.
updates any 443 The appliance downloads updates over https. Please see the table below for a list of specific URLs that are being used.
admin 222 Use specific management ip's if you can for ssh access to the appliance.
LDAP LDAP server 389/636 If LDAP authentication is enabled, the appliance needs connections to the LDAP server.
NTP any / ntp server 123 (UDP) If NTP time synchronisation is enabled, if NTP pool authentication is enabled the destination needs to be any.
Emaildrop any 25 If you have enabled Emaildrops.
FTPdrop (FTP) any 21, 44000-44100 If you have configured FTPdrops and wish to use FTP.
FTPdrop (SFTP/SCP) any 22 If you have configured FTPdrops and wish to use SFTP/SCP.

In most cases, if deployed behind a firewall or similar, you will also need to configure the firewall for address translation — translating a public address to the private address. You will also mostly certain need to configure DNS so that a published DNS points to the public ip address of the Filetransfer appliance.

Restricting outgoing https

The following table outlines all connections where LiquidFiles is using when connecting to the Internet.

Function Destination Comment
Licenses/ Updates When installing/renewing licenses, the LiquidFiles system will validate its license with the license details stored at Also, when performing updates, LiquidFiles will check available updates from
Updates Any LiquidFiles, System, AV Updates or Hotfixes will be downloaded from
Please note that is using Amazon Cloudfront (global geo-caching). You will not be able to restrict this to specific IP addresses.
GeoIP Lookups If you have enabled GeoIP lookups, the LiquidFiles system will lookup IP → GeoIP locations to
Support Info If you need to send Support Information (diagnostic information sometimes requested by LiquidFiles support), this will be sent from the LiquidFiles system to
Support Connection tcp:// If you need to enable the Support Connection (when requested by LiquidFiles support), this will establish a connection on TCP Port 443 to Please note that eventhough this is using TCP Port 443, it is not using HTTPs so if you are using any content inspecting firewall or similar, you may need to disable HTTPs checking for the support connection to be able to be established.

If required, you can also configure a Proxy in Admin → System → Network and that will make all outgoing connections use the proxy instead of going direct.

DNS Considerations

Some organisations like to use different names for internal and external resources, giving resources like LiquidFiles names like and liquidfiles.local for external and internal use respectively, just like they would if LiquidFiles was an intranet application.

LiquidFiles is a little bit different from most other applications though as it sends email referencing itself (something a webmail system for instance never would do). And one of the key architectural decisions with LiquidFiles is — don't break how emails normally work. Consider the following message:

From: <>
To: <>
CC: <>
Subject: You're fired

Homer, you're fired. Here's a link to your letter of dismissal:

If we assume that and are internal users and is external. If we sent a link with the URL to the LiquidFiles system as https://liquidfiles.local, would not be able to reach it. If we split the email and sent individual emails to and with links to https://liquidfiles.local and with a link to, none of the receipients would see who else is copied on the message, one of the key functions of the email header. We therefore have to send the same email to everyone.

Our only workable option is to make the same name resolvable and reachable from everywhere. In this example that would be:

Depending on our infrastructure, this could be accomplished by:

  • Making sure that the public ip address for the LiquidFiles system is routable everywhere
  • Use split view/dual DNS to either provide the external or internal ip address for the LiquidFiles system depending on the location of the user.

In most cases, split view or dual DNS configuration is the preferable option. This will enable you to use an external ip address for for external users, and an internal ip address for internal users. If we use the same ip address both internally and externally, we often end up having to address translate external addresses when trying to make them reachable in a DMZ from internal addresses. But whatever method you are comfortable with, as long as you can use the same name ( from anywhere, it really doesn't matter how you achieve it.

Email Considerations

Another thing that often causes issues, primarily with test installations in large enterprises, is delivering emails.

LiquidFiles has two options when delivering emails:

  1. Direct delivery — use DNS to lookup the mail server for each recipient and deliver the email directly with SMTP. This is the same functionality as any email server on the Internet would use to send emails.
  2. Use an Email relay server — send all emails to a configured email relay server. Let the email relay server deliver all emails on behalf of the LiquidFiles system.

The reason why this sometimes can be challenging is that with 1) connections from the inside out is often firewalled in large enterprises, so the LiquidFiles system can't connect to the required SMTP servers and deliver the emails. And with 2) the typical email server configuration does not permit the unrestricted email relaying LiquidFiles requires.

To expand on the latter. When the LiquidFiles system sends an email, the email header looks something like this:

From: <>
To: <>
CC: <>
Subject: You're fired

But could just as easily be:

From: <>
To: <>
CC: <>
Subject: What took you so long?

The From field is going to be the email address of the user who is sending the message in LiquidFiles and the To, CC and BCC fields are going to be whatever the logged in user has entered. Usually the From field is what's causing issues as it can be an internal user (like above) or an external user ( We can therefore not place any limitations on either the From or the To field.

If we compare this how the email header looks when sending from something like Outlook. In Outlook the From field is always going to be the same. In most email servers, the user will have to authenticate to relay (send) the email and when they authenticate, they have to send as the user they authenticated as. So if the email above was composed by using Outlook to send through his local Ms Exchange server, Outlook would authenticate as and allow him to send the email. But could not authenticate as and then enter in the From field. The email server would not permit this.

If we instead compare the LiquidFiles email to how say a NAS server email alert email looks. This is again different in that the To field is always the same. In the email server we can configure emails to always be allowed to something like so that all devices that sends monitoring emails can send them to this address.

And this is where it is sometimes difficult to test LiquidFiles in environments that are locked down. LiquidFiles needs to be permitted to send emails From anyone and To anyone. This is of course unless you are building a strict internal system, in which case you can limit to only be permitted From and To the specific addresses you permit. But in the overwhelmingly majority of cases, you will have to permit the LiquidFiles system to send From anyone and To anyone.

There are typically two options to achieve this when using the email relay option:

  • Configure the email server you are relaying through to permit the ip address of the LiquidFiles system unrestricted email relay permissions.
  • Configure a user in the email server ( unrestricted email relay permissions in the mail server.

In both cases, please refer to your email server configuration for instructions how to configure unrestricted email relaying for the LiquidFiles system.

The only other option is to not use an internal email server to relay the emails and instead use a public available email relay service like ElasticEmail. Mandrill (by the same company as Mailchimp) is a service specifically built to relay emails from system like LiquidFiles. In case of a strict locked down network, you would only need to open connections from the ip address of the LiquidFiles system to instead of permitting unrestricted SMTP access, or change the configuration of your mail server. So this may well be the simplest option.

If you run into problems with email delivery, please see the Troubleshooting Email Delivery article.

Please continue on the System Requirements page.