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.
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.
Don’t forget to set up the cron jobs as outlined in the installation instructions.
If you’re using Passenger, refer to the
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.
You must change all key-related config settings
general.yml from their default values. This includes (but may not be limited to!)
You should consider running the admin part of the site over HTTPS. This can be
achieved with rewrite rules that redirect URLs beginning with
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
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
Refer to the Postgres
database backup strategies. The most common method is to use
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
if error_message then finish endif if $header_to: contains "mydomain.org" then unseen deliver "firstname.lastname@example.org" endif if $sender_address: contains "mydomain.org" then unseen deliver "email@example.com" endif
We strongly recommend you use a deployment mechanism to make changes to your production site.