Search TipsFlix Server Technical Overview
This technical overview aims to give Systems Administrators and Tech Teams deploying Flix in a studio environment some context as to what the requirements are, how it works under the hood, and to provide a high level understanding of Flix’s overall architecture.
This overview assumes some familiarity with systems administration and client/server architecture.
Architecture
Flix is a client / server architecture application. The client (Flix Client) is the user interface for interacting with Flix, creating boards, viewing sequences, and interaction with third-party tools like Photoshop. The server side (Flix Server) is where the bulk of Flix’s processing takes place. Flix Server provides a RESTful HTTP API for Flix Client, or custom scripts, to consume. Communication between Flix Client and Flix Server is done over HTTP(S) and Websockets.
The server utilizes a MySQL database for data persistence of shows, episodes, sequences, panels, dialogue, and so on. Although the database holds image data, such as panel thumbnails or artwork, it doesn’t store the actual files or assets. These are stored in a separate asset location. Each Flix Server requires access to the same MySQL server to operate.
Flix Server handles all image transcoding, manipulation, and storage. Asset storage on the server can be local, or on a network share. Flix can be configured to use either option. Network shares must be presented to Flix as a file system directory.
Server Requirements
Flix Server can be installed on a physical server or virtual machine, and it’s recommended to have multiple servers set up in your Flix deployment to provide scalability and redundancy. Flix spreads requests across servers equally, to ensure all servers resources are used to their full extent.
A single-server setup can be enough for a small deployment (3-5 users), but a multi-server setup is better suited to a larger user base, especially for workflows which involve greater involvement with Editorial. Servers can be added after the initial setup to scale up when needed.
Note: Flix handles its own load-balancing, so we do not recommend adding another load-balancer to your deployment, such as Varnish.
Hardware Specifications
The recommended hardware specs for Flix Server are highly dependent on usage. The main areas that require considerable resources are image processing and file transfers. Image processing in Flix is mostly handled on the server side, so the server requires resources to do these tasks. These tasks can be CPU intensive, especially the creation of DNxHD for Avid Media Composer. More powerful CPUs process images faster, resulting in faster editorial round-trips and panel creation.
Note: Flix Server does not require a GPU.
Flix Server architecture is built on the basis of concurrency and requires multiple CPU cores to operate effectively. Flix Server requires a CPU with a minimum of 2 cores, but we recommend 4 cores, or more, to allow Flix to multitask more effectively.
The number of tasks Flix Server can perform also depends on the amount of available RAM. More concurrent tasks may require more memory, so having enough RAM available is essential for good performance. A minimum of 4 GB of RAM is required, but we recommend 8 GB or 16 GB for larger installations.
Flix Server can be scaled in two different ways, horizontally and vertically. Horizontal scaling refers to the number of nodes, or servers, in your cluster. Vertical scaling refers to the amount of resources available to each of your nodes, such as CPU cores and RAM. Scaling in each direction provides a distinct advantage to your Flix installation:
• Horizontal Scaling
Increases API throughput and allows more Flix Client connections
Reduces load on each node in the cluster (if you have high resource utilization on your Flix Servers, you may want to scale horizontally)
Adds redundancy and prevents downtime if a server outage occurs
Adds pressure to your database server
• Vertical Scaling
Improves rendering speed
Reduces time for panel creation
Improves DNxHD rendering speeds
Each server can handle more tasks concurrently
Storage
Flix Server stores and manages all of the assets imported in Flix as panels, audio files, AAFs, and so on, and therefore requires access to a file share with enough free storage. The storage requirements vary heavily depending on the size of the production, its duration, and the type of usage it sees from Flix Clients.
1 TB storage for a feature production is a good recommendation as a starting point, as long as this can be expanded on as needed.
Flix Server stores the assets on the machine it's running on by default, but we highly recommend pointing Flix Server to an external file share. The external file share can then be accessed by multiple Flix Servers to avoid data duplication and to centralize all of your assets. If you configure Flix Server to use a shared network mount, we recommend you use the ‘shared storage’ feature, to allow any Flix Server to serve assets. Using this feature decreases unnecessary data duplication in your assets directories.
Flix stores all assets in the Asset directory, which is configured on the server. This directory is managed by the Flix Servers, and should not be directly accessed by sysadmins or artists.
Warning: We strongly advise against renaming, deleting, or tampering with files from the Asset directory, as it may cause failures in Flix or result in missing media.
Flix supports any file system available on the operating system. Flix expects a mounted file system directory with full read and write permissions to function correctly. SMB or NFS are recommended as they are widely available, though NFS setups perform better in some instances.
Assets are partitioned by Show in the Asset directory for the purposes of archiving, if required. Once a show becomes old, and no longer in use, its assets can be moved out of the Asset directory for backup purposes to free up storage availability. However, any access to assets requested for those shows is no longer available and appears offline within Flix.
Database
Flix uses the relational database MySQL for data persistence. MySQL has many features making data storage efficient and scalable and it is a tried and tested database server, ensuring we have a reliable data storage layer.
All persistent data in Flix is stored in the database, except for the assets, which are stored on the file system separately. However, metadata for the assets, including location and naming, is stored in the database. This ensures we don’t have to access the file system when querying asset data, which can be incredibly fast if the data is in the database's caches. This way, Flix doesn’t rely on continuous reads that can put a lot of pressure on file system storage.
Article: If you want to learn more about what info is stored in the database and how this is connected to the assets and Flix, take a look at this Knowledge Base Article.
It is imperative that you back up the Flix databases, along with your Asset directories regularly to prevent data loss. Backups of the database can be completed using Flix Server and the --db-backup command. Backups can also be completed using MySQL directly for more advanced users.
Article: For more information on backing up your Flix database, take a look at this Knowledge Base Article.
Flix installs all the relevant MySQL tables on startup, when required. You are prompted to backup your databases whenever Flix needs to make schema changes. Flix makes full use of database normalization to ensure data integrity and improved performance. We do not recommend making direct data changes to the database as this could cause unexpected data inconsistencies.
Flix performs a wide variety of actions on the database and requires an extended permission set. Flix checks your permissions on start-up to ensure it has the correct privileges.
API and Websockets
Flix Server provides a RESTful API over HTTP(S). This API manages the majority of data creation and retrieval on the server. The API not only allows for Flix Client to communicate with the server, but it also allows for a high degree of interoperability between other software, including your own custom scripts.
When a client makes a request to the server Flix Server ensures that the request is valid and then takes the appropriate action. For example, creating a show in Flix Client causes Flix Server to store the show information in the database. Once stored, the server creates a response message to the client to indicate that the operation was successful.
Flix also uses websockets for realtime communication between the client and server. We use websockets mostly for signalling purposes. For example, when the server has completed a long-running operation, it then notifies the client using a websocket message that it is complete, allowing the UI to be updated. This is a very performant way of providing realtime interactivity between the client and server. For Flix to work effectively, it needs to maintain a connection between the client and server. Flix notifies you if the connection drops at any time by displaying a Reconnecting to Flix popup.
Security
Flix is designed with security in mind to ensure we can commit to remote working capabilities. All communication between Flix Client and Flix Server is over HTTP(S), which is a widely accepted and well understood communication protocol allowing us to take full advantage of the features it provides. Using HTTPS (SSL/TLS) encrypts communication packets between the client and server. This ensures that the data cannot be intercepted and read by a third-party in transit. This is especially important for remote working with Flix to prevent data leaks.
HTTPS requires you to create certificates for your servers using well known software such as OpenSSL or a third-party vendor who can generate certificates for you.
Flix also signs all HTTP requests between the client and server for authorization and security purposes. Flix uses private and public keys for each user to sign each request. This ensures that when the request reaches the server, it is guaranteed to be the same request that was sent from the client, eliminating the possibility of man-in-the-middle attacks.
See Setting Up HTTPS for more information on configuring Flix to run over HTTPS.
Licensing
To make it easy on artists, Flix Client is a non-licensed application, meaning anyone can download and launch it. Flix Server, however, requires a license to run, and handles the authentication of artists logging in using Flix Client.
For Flix deployments with a single server, the easiest licensing method is using a node-locked license, installed on the server/VM used to run Flix Server. For multi-server Flix deployments, we recommend using a server, or floating, license instead. This option shares a single license file between all the servers, rather than having a node-locked license on each Flix Server. Floating licenses can be installed on a dedicated License Server or on one of the servers/VMs running Flix Server in your deployment. Flix uses the same licensing mechanism as every other Foundry product. More detailed information on the Foundry’s licensing can be found in our Licensing Documentation.
Flix licenses control how many clients can be logged in to Flix concurrently. If you have a 10-seat Flix license, 10 clients can work in Flix at the same time, but an 11th client is denied access.
See Licensing Flix Server for more information.
Remote Access
Flix is designed for artists to be able to log in from anywhere, whether they’re on premises or working remotely.
To achieve this, the server and port on which Flix Server is running must be reachable by the artist’s Flix Client app publicly or over a virtual private network (VPN).
We recommend using a fully qualified domain (FQDN) for each Flix Server you set up for remote artists. The domain name must be resolvable by the Flix Client app for Flix to work.
Minimum Bandwidth Requirements for Flix
The table below shows a series of tests at different bandwidths and the corresponding results. We cannot guarantee that Flix will work if your internet speed is below 4 Mbps. For the optimal experience of Flix, we recommend using an internet speed of or above 16 Mbps.
| Action | Filesize (MB) | Bandwidth (megabits/second) | Latency (ms) | Time Taken | Errors/Warnings | Significance |
| Manual Import | 245.7 | Control: 60 gigabit/second | 0 | 2:45 | None | Maximum Bandwidth |
| Manual Import | 245.7 | 0.25 | 0 | >30 min | Error: chunk upload took too long, ~17 seconds | |
| Manual Import | 245.7 | 0.5 | 0 | >30 min | Warning: chunk upload was a little slow: ~9 seconds | |
| Manual Import | 245.7 | 1 | 0 | >30 min | Warning: chunk upload was a little slow: ~4.5 seconds | |
| Manual Import | 245.7 | 2 | 0 | 25 min | Warning: chunk upload was a little slow: ~2 seconds | |
| Manual Import | 245.7 | 2.5 | 0 | 22 min | None | Minimum Bandwidth |
| Manual Import | 245.7 | 3 | 0 | 17:45 | None | |
| Manual Import | 245.7 | 4 | 0 | 13:40 | None | |
| Manual Import | 245.7 | 6 | 0 | 10:35 | None | |
| Manual Import | 245.7 | 8 | 0 | 8:05 | None | |
| Manual Import | 245.7 | 10 | 0 | 6:35 | None | |
| Manual Import | 245.7 | 15 | 0 | 5:35 | None | |
| Manual Import | 245.7 | 20 | 0 | 4:45 | None | |
| Manual Import | 245.7 | 30 | 0 | 3:55 | None |
