Warning! This documentation is outdated. Visit help center for the latest documentation.

Configuring server options

Config options are used to enable or disable certain features or behavior in ftrack. They are specified on the ftrack server in /opt/ftrack_config/ftrack.ini under the [DEFAULT] section. After modifying the config file ftrack must be restarted for the changes to apply.

Service secret

A service secret is required to have internal services working properly. A secret needs to be generated and added to the ini file.

ftrack.service_secret = SOME_SECRET

The secret should be random and at least 36 characters long. A secret can be generated like this:

python -c 'import uuid;print uuid.uuid4()'

Server URL

The server URL needs to be set to let ftrack know what URL your users will be using to connect to the server. The URL is used to generate emails correctly and ensure some of the internal services are working properly. The URL should contain protocol.

ftrack.server_url = http://my-company-ftrack


The URL must be accessible from the ftrack server as it will also be used for internal communication.


Email settings should be configured to allow the ftrack server to send out notifications via email.

# Turbomail config.
mail.on = true
mail.transport = smtp
mail.smtp.server = YOUR-SMTP-SERVER_URL:PORT
mail.encoding = utf-8
mail.smtp.username = USERNAME
mail.smtp.password = PASSWORD
mail.message.author = ftrack <no_reply@YOUR-COMPANY.com>

You can also configure ftrack to send error emails when a server error happens using:

# Error email config.
ftrack.error_email = ftrack-error@YOUR-COMPANY.com
ftrack.smtp_server = YOUR-SMTP-SERVER_URL:PORT
ftrack.from_address = ftrack <no_reply@YOUR-COMPANY.com>
ftrack.smtp_username = USERNAME
ftrack.smtp_password = PASSWORD


We recommend that you track errors with sentry instead of via emails.


You can test sending emails from the ftrack diagnostics page in system settings. Either to your user, or by triggering a server error which will send to the error email config.

PDF export font

Specify the font file that should be used when exporting a PDF.

ftrack.pdf_export_font_path = /ABSOLUTE_PATH_TO_FONT/FONT.ttf


The path have to be an absolute path and the font must be in ttf format.

Custom layouts

Specify a folder with JSON configuration files.


The configuration files are loaded when the server starts. To apply new changes, the server needs to be restarted.

ftrack.form_layout_path = /PATH/TO/FOLDER/WITH/LAYOUTS

Read more about layouts

Due date in Tasks widget

Enable due date column in Tasks widget in sidebar.


Configure Web server

The main ftrack server is using uWSGI which has a lot of configuration options that can be used to tune ftrack for better performance.


Always use a staging server when tuning ftrack to test various options before deploying in production.

The default options are passed to uwsgi when it is started but can be overridden in the ftrack ini file by adding a uwsgi section:

processes = 15

By default ftrack will use 10 processes and that should be enough for most scenarios. Each process have 10 threads that are responsible of serving requests. Increasing the number of processes will allow the ftrack server to serve more requests at the same time.


Each process will consume additional RAM which may increase slightly over time. There is also a certain ratio between number of CPUs on your server and the number of processes that make the server efficient. As an example, having 2 CPU cores and 20 processes is likely not going to result in better performance when the number of concurrent requests against the server is high.


If you are running the database on the same server you should make sure you never run out of RAM since that will likely result in the database failing to allocate memory and crash.


Tuning a server is not an exact science as it depends on a lot of factors. Keep an eye on CPU usage and disk IO when tuning your server to get an idea of what is the main bottleneck. There are a few tools that can be used to monitor the processes and the number of requests they serve.


/opt/ftrack/environments/ngxtop/bin/ngxtop -l /tmp/ftrack_nginx.log

Can be used to monitor all requests passing through Nginx and look at their response codes in real time. ngxtop parses the access log and can also be used to look and past requests like this:

/opt/ftrack/environments/ngxtop/bin/ngxtop -l /tmp/ftrack_nginx.log --no-follow


The processes running in uWSGI can be monitored individually to ensure they are serving content properly using:

/opt/ftrack/environments/uwsgi/bin/uwsgitop /tmp/uwsgi_stats.sock

Track exceptions with sentry

Sentry can be used to capture exceptions happening in ftrack to see when and how often they occur. To capture exceptions with sentry the ftrack.ini file needs to be updated with the following:

ftrack.sentry = true

To use sentry on your local install you need to have a sentry account and there you can find your sentry dsn.

You can also use sentry to track exception which occur in client-side applications by creating a new project in Sentry and adding the corresponding public DSN key to the configuration file.

ftrack.sentry_dsn_ftrack_spark_overview = https://...

Fetch update events directly from internal queue

Update events can be listened to using the event hub in the API. Sometimes it is useful to get the events directly from the internal events queue to guarantee that no events are missed due to dropped connections or similar between the API and the event server.


For this to work, the event server must enable use of the amqp messaging queue via the configuration option:

ftrack.enable_amqp_event_server = true

This feature will be enabled by default in later releases once it has been proven to have no performance or stability implications.

When an event is generated on the ftrack server it is added to the amqp messaging queue via an exchange called ftrack-events. The ftrack event server will register a queue bound to that exchange called ftrack-event-server-queue and use that to process the events. If you want to gather the events directly from the amqp messaging queue you can register your own queue via the same exchange and read the events from there. This ensures that events are never missed even if your script is restarted.

Override the default create project behavior

You can override the default behavior when a user chooses to create a new project to invoke an action instead of displaying the default dialog:

# Set to an action identifier to be launched when creating a project
ftrack.create_project_action_identifier = test.company.create-project

An minimal example action which creates a project is available here: create_project_action.py.


If you need to override the default create project behavior, but are running in a cloud hosted environment, please let us know at support@ftrack.com.