Hardware Requirements

The hardware requirements depend on the number of users that will access the Web Portal. Exact sizing will depend on how heavily the portal is used and how many users access the portal concurrently.

To operate a TeamDrive Web Portal you need one or more 64-bit systems.

CPU usage, RAM, disk storage and network requirements are described below. Since the usage of a Web Portal can differ greatly, our recommendations are only approximate.

Note that the requirements describe here apply in particular to the system running the Docker host. The hardware requirements of the other components of the Web Portal are minimal in comparison, and can be set at approximately 10% of the power of the Docker service. See Scaling a TeamDrive Web Portal Setup for more details.

Please contact us via sales@teamdrive.net for further assistance.

CPU Requirements

To operate a TeamDrive Web Portal we recommend at least one processor core per 24 users of the portal.

This estimate assumes that only about 10% of all users are actively performing some operation at any given moment. Increase the number of CPU cores If your estimate of the number of active users is higher.

RAM Requirements

The Web Portal starts a Docker container running the TeamDrive Agent for each active user session. Each container requires about 100 MB of RAM.

You can assume that the number of containers running is greater than the number of active users (the number of users accessing the portal at any given time). This is because a container continues running until the user session is closed due to an idle timeout.

Storage Requirements

The main storage requirement is for the Space data that is downloaded from the Hosting Service when a user enters a Space via the TeamDrive Web interface.

The storage requirements are relatively modest because only the “meta-data” (file names and directory structure) of a Space will be stored permanently on the Web Portal.

The rest of the disk space required consists of a file cache which is used for files in transit between the Hosting service and the end-user device. We recommend a cache size of at least 2 GB per Web Portal user plus about 4 MB per Space.

The speed of the storage system used will be decisive for the responsiveness of the Web Portal, in particular when entering a Space. We recommend a system that is capable of at least 100 IOPS per active user of the Portal. As a rule of thumb we assume that 10% of the users that use a Web Portal are active at any particular time. This means, for example, that if a portal serves 1000 users, then the storage system should be capable of 10000 IOPS.

For Web Portals running on a cluster of host machines, the storage system must be mounted by all hosts in the cluster.

If a user’s account is idle for a certain period of time (for example 1 month), the Web Portal can be instructed to remove the user’s data. In this way, the storage can be freed up for other users.

If the user’s data is removed from the Web Portal host, the data is not lost, because the Space data is still stored and maintained by the Hosting Server. The only inconvenience for the user is that Spaces will have to be “re-entered” the next time the user logs in to the Web Portal.

Another volume will be needed by docker to store the container images and running instances. An overview can be found here:

The recommended storage configuration for production use is using the direct-lvm (logical volume manager) as the preferred storage driver. Configure the volume as described in this instruction after installing and before starting docker the first time:

Network Requirements

The bandwidth of the Web Portal’s network interface plays a vital role in defining the overall performance and responsiveness of the service.

When a user enters a Space, the meta data of the Space will be downloaded to the Web Portal. The speed of this operation will be effected by the speed of inbound connections.

When a user accesses a file in a Space, the file is first downloaded to the Web Portal disk cache for the user, where it is decrypted. The decrypted file is then transferred to the user’s device. As a result, the amount of inbound traffic is at least as high as the outgoing traffic.

The system must have IP connectivity, using a fixed IP address and a resolvable fully qualified domain name. This host name is basically the URL that users will use to access the Web Portal. The Web Portal itself needs to be able to properly resolve host names, too.

If the Web Portal is located behind a firewall, please ensure that it is reachable via HTTPS (TCP port 443) by a web browser.

During operation the Web Portal will need to make API calls to an associated TeamDrive Registration Server. For this purpose the Web Portal must be able to establish outgoing HTTPS connections to the Registration Server.

It is possible to use an TeamDrive Authentication Service for the TeamDrive users of the Web Portal, or an external authentication for the administrators of the Web Portal. In this case, the Web Portal must be able to establish HTTP or HTTPS connections (depending on the configuration) with the host running the authentication service.