Deployment of a Mezzanine site to production is mostly identical to deploying a regular Django site. For serving static content, Mezzanine makes full use of Django’s staticfiles app. For more information, see the Django docs for deployment and staticfiles.


Each Mezzanine project comes bundled with utilities for deploying production Mezzanine sites, using Fabric. The provided contains composable commands that can be used to set up all the system-level requirements on a new Debian based system, manage each of the project-level virtual environments for initial and continuous deployments, and much more.

Server Stack

The deployed stack consists of the following components:


None of the items listed above are required for deploying Mezzanine, they’re simply the components that have been chosen for use in the bundled Alternatives such as Apache and MySQL will work fine, but you’ll need to take care of setting these up and deploying yourself. Consult the Django documentation for more information on using different web and database servers.


Configurable variables are implemented in the project’s module. Here’s an example:

    "SSH_USER": "", # SSH username
    "SSH_PASS":  "", # SSH password (consider key-based authentication)
    "SSH_KEY_PATH":  "", # Local path to SSH key file, for key-based auth
    "HOSTS": [], # List of hosts to deploy to
    "VIRTUALENV_HOME":  "", # Absolute remote path for virtualenvs
    "PROJECT_NAME": "", # Unique identifier for project
    "REQUIREMENTS_PATH": "requirements/project.txt", # Path to pip requirements, relative to project
    "GUNICORN_PORT": 8000, # Port gunicorn will listen on
    "LOCALE": "en_US.utf8", # Should end with ".utf8"
    "LIVE_HOSTNAME": "", # Host for public site.
    "REPO_URL": "", # Git or Mercurial remote repo URL for the project
    "DB_PASS": "", # Live database password
    "ADMIN_PASS": "", # Live admin user password


Here’s the list of commands provided in a Mezzanine project’s Consult the Fabric documentation for more information on working with these:

  • fab all - Installs everything required on a new system and deploy.
  • fab apt - Installs one or more system packages via apt.
  • fab backup - Backs up the database.
  • fab create - Create a new virtual environment for a project.
  • fab deploy - Deploy latest version of the project.
  • fab install - Installs the base system and Python requirements for the entire server.
  • fab manage - Runs a Django management command.
  • fab pip - Installs one or more Python packages within the virtual environment.
  • fab psql - Runs SQL against the project’s database.
  • fab python - Runs Python code in the project’s virtual environment, with Django loaded.
  • fab remove - Blow away the current project.
  • fab restart - Restart gunicorn worker processes for the project.
  • fab restore - Restores the database.
  • fab rollback - Reverts project state to the last deploy.
  • fab run - Runs a shell comand on the remote server.
  • fab sudo - Runs a command as sudo.

Twitter Feeds

If Twitter feeds are implemented in your templates, a cron job is required that will run the following management command. For example, if we want the tweets to be updated every 10 minutes:

*/10 * * * * python path/to/your/site/ poll_twitter

This ensures that the data is always available in the site’s database when accessed, and allows you to control how often the Twitter API is queried. Note that the Fabric script described earlier includes features for deploying templates for cron jobs, which includes the job for polling Twitter by default.

As of June 2013, Twitter also requires that all API access is authenticated. For this you’ll need to configure OAuth credentials for your site to access the Twitter API. These settings are configurable as Mezzanine settings. See the Configuration section for more information on these, as well as the Twitter developer site for info on configuring your OAuth credentials.

Table Of Contents

Previous topic


Next topic

Frequently Asked Questions

This Page