Production server best practices

These notes serve as a checklist of things to consider when you're ready to deploy your Alaveteli site to production.

Hosting options

Your production server must be reliable and secure. If you don’t run your own servers already, consider one of these options:

  • Cloud Server
  • Virtual Private Server

In some cases, we can host new Alaveteli projects — if you need help, ask us about hosting.

Cron jobs

Don’t forget to set up the cron jobs as outlined in the installation instructions.

Webserver configuration

We recommend running your site behind Apache + Passenger or Nginx + Thin.

If you’re using Passenger, refer to the installation instructions regarding PassengerMaxPoolSize, which you should experiment with to match your available RAM. It is very unlikely that you’ll ever need a pool larger than Passenger’s default of 6.

We recommend you run your server behind an HTTP accelerator like Varnish. Alaveteli ships with a sample varnish VCL.

If your hosting company supports IPv6 make sure that you’ve enabled this and configured an AAAA record in your domain’s DNS zone for capable clients.


You must change all key-related config settings in general.yml from their default values. This includes (but may not be limited to!) these settings:

You should consider running the admin part of the site over HTTPS. This can be achieved with rewrite rules that redirect URLs beginning with /admin.

Additionally, the INCOMING_EMAIL_DOMAIN should not be the one that you use for your organisational email. Mail sent to Alaveteli request addresses is published on the site, and using an organisational email domain could leave you vulnerable to attacks that sign up for your internal tools using these addresses and use Alaveteli to receive and publish confirmation emails. Use a completely different domain or a subdomain of your organisational domain. See this blog post for a description of this kind of attack.

Email configuration

See the configuration for exim or postfix for setting up your Mail Transfer Agent (MTA). It is possible to use other MTAs — if you use a different one, the documentation there should provide you with enough information to get started. If this applies to you, please add to the documentation!

On a live server, you should also consider the following, to increase the deliverability of your email, particularly if you are using the batch request feature that might generate higher than usual volumes:

  • Set up SPF records for your domain
  • DKIM sign messages
  • Set up DMARC
  • Consider the source IP and ensure that it isn’t being used for lots of other things that might cloud your reputation - eg relaying through a service can cause problems
  • Set up feedback loops with the main email providers (Hotmail and Yahoo! are recommended)
  • Especially if deploying from Amazon EC2, use an external SMTP relay for sending outgoing mail. See Alaveteli EC2 AMI for more suggestions.


Most of the data for the site lives in the production database. The exception is the raw incoming email data, which is stored on the filesystem, as specified in the setting RAW_EMAILS_LOCATION setting in config/general.yml.

Refer to the Postgres documentation for database backup strategies. The most common method is to use pg_dump to create a SQL dump of the database, and backup a zipped copy of this.

Raw emails would be best backed up using an incremental strategy. Rsync is one way of doing this.

Another belt-and-braces backup strategy is to set up your MTA to copy all incoming and outgoing mail to a backup mailbox. One way of doing this with exim is to put the following in your exim config:

system_filter = ALAVETELI_HOME/config/exim.filter
system_filter_user = ALAVETELI_USER

And then create a filter file at ALAVETELI_HOME/config/exim.filter, with something like:

if error_message then finish endif
if $header_to: contains ""
unseen deliver ""

if $sender_address: contains ""
unseen deliver ""


We strongly recommend you use a deployment mechanism to make changes to your production site.