Django’s built-in runserver is not suitable for a production deployment; use a WSGI-compatible webserver such as Apache with mod_wsgi, or gunicorn. A WSGI application callable is provided in moztrap/deploy/ in the application object.

You’ll also need to serve the static assets; Apache or nginx can do this.

You’ll need a functioning SMTP server for sending user registration confirmation emails; configure the EMAIL_* settings and DEFAULT_FROM_EMAIL in your moztrap/settings/ to the appropriate values for your server.

The default local-memory cache backend is not suitable for use with a production (multi-process) webserver; you’ll get CSRF errors on login because the CSRF token won’t be found in the cache. You need an out-of-process cache backend: memcached or Redis is recommended for production deployment. The Django file or database cache backends may also work for a small deployment that is not performance-sensitive. Configure the CACHE_BACKENDS setting in moztrap/settings/ for the cache backend you want to use.

In addition to the notes here, you should read through all comments in moztrap/settings/ and make appropriate adjustments to your moztrap/settings/ before deploying this app into production.


By default all access to the site requires authentication. If the ALLOW_ANONYMOUS_ACCESS setting is set to True in moztrap/settings/, anonymous users will be able to read-only browse the management and test-results pages (but will not be able to submit test results or modify anything).

By default MozTrap uses BrowserID for all logins, but it also supports conventional username/password logins. To switch to username/password logins, just set USE_BROWSERID to False in moztrap/settings/

If using BrowserID (the default), you need to make sure that your SITE_URL is set correctly in moztrap/settings/, or BrowserID logins will not work.

Vendor library

For deployment scenarios where pip-installing dependencies into a Python environment (as bin/install-reqs does) is not preferred, a pre-installed vendor library is provided in requirements/vendor/lib/python. This library does not include the compiled dependencies listed in requirements/compiled.txt; these must be installed separately via e.g. system package managers. The site.addsitedir function should be used to add the requirements/vendor/lib/python directory to sys.path, to ensure that .pth files are processed. A WSGI entry-point script is provided in moztrap/deploy/ that makes the necessary sys.path adjustments, as well as a version of in

If you are using the vendor library and you want to run the MozTrap tests, bin/test won’t work as it uses Instead run python test.

If you need code coverage metrics (and you have the coverage module installed; it isn’t included in the vendor library as it has a compiled extension), use this:

coverage run test
coverage html
firefox htmlcov/index.html


In a production deployment this app should be served exclusively over HTTPS, since almost all use of the site is authenticated, and serving authenticated pages over HTTP invites session hijacking attacks. The SESSION_COOKIE_SECURE setting should be set to True in moztrap/settings/ when the app is being served over HTTPS.

Run python checksecure on your production deployment to check that your security settings are correct.

Static assets

This app uses Django’s staticfiles contrib app for collecting static assets from reusable components into a single directory for production serving, and uses django-compressor to compress and minify them. Follow these steps to deploy the static assets into production:

  1. Ensure that COMPRESS_ENABLED and COMPRESS_OFFLINE are both uncommented and set to True in moztrap/settings/
  2. Run python collectstatic to collect all static assets into the collected-assets directory (or whatever STATIC_ROOT is set to in moztrap/settings/
  3. Run python compress to minify and concatenate static assets.
  4. Make the entire resulting contents of STATIC_ROOT available over HTTP at the URL STATIC_URL is set to.

If deploying to multiple static assets servers, probably steps 1-3 should be run once on a deployment or build server, and then the contents of STATIC_ROOT copied to each web server.

Database performance tweak

In order to ensure that all database tables are created with the InnoDB storage engine, MozTrap’s default settings file sets the database driver option “init_command” to “SET storage_engine=InnoDB”. This causes the SET command to be run on each database connection, which is an unnecessary slowdown once all tables have been created. Thus, on a production server, you should comment this option from your moztrap/settings/ file’s DATABASES setting after you’ve run python syncdb --migrate to create all tables (uncomment it before running python syncdb or python migrate after an update to the MozTrap codebase, or before trying to run the tests).