Throughout this book, we\u2019ve mentioned a number of goals that drive the development of Django. Ease of use, friendliness to new programmers, abstraction of repetitive tasks \u2014 these all drive Django\u2019s developers. However, since Django\u2019s inception, there\u2019s always been another important goal: Django should be easy to deploy, and it should make serving large amounts of traffic possible with limited resources.<\/p>\n
The motivations for this goal are apparent when you look at Django\u2019s background: a small, family-owned newspaper in Kansas can hardly afford top-of-the-line server hardware, so Django\u2019s original developers were concerned with squeezing the best possible performance out of limited resources. Indeed, for years Django\u2019s developers acted as their own system administrators \u2014 there simply wasn\u2019t enough hardware to need<\/em> dedicated sysadmins \u2014 even as their sites handled tens of millions of hits a day.<\/p>\n As Django became an open source project, this focus on performance and ease of deployment became important for a different reason: hobbyist developers have the same requirements. Individuals who want to use Django are pleased to learn they can host a small- to medium-traffic site for as little as $10 a month.<\/p>\n But being able to scale down is only half the battle. Django also needs to be capable of scaling up<\/em> to meet the needs of large companies and corporations. Here, Django adopts a philosophy common among LAMP-like Web stacks often called shared nothing<\/em>.<\/p>\n What\u2019s LAMP?<\/strong> -The acronym LAMP was originally coined to describe a popular set of open source software used to drive many Web sites:<\/p>\n Over time, though, the acronym has come to refer more to the philosophy of these types of open source software stacks than to any one particular stack. So while Django uses Python and is database-agnostic, the philosophies proven by the LAMP stack permeate Django\u2019s deployment mentality. There have been a few (mostly humorous) attempts at coining a similar acronym to describe Django\u2019s technology stack. The authors of this book are fond of LAPD (Linux, Apache, PostgreSQL, and Django) or PAID (PostgreSQL, Apache, Internet, and Django). Use Django and get PAID!<\/p>\n To deploy your Django application, you\u2019ll need to hook it into an industrial-strength Web server such as Apache.<\/p>\n The Internet is a hostile environment. Before deploying your Django project, you should take some time to review your settings, with security, performance, and operations in mind.<\/p>\n Django includes many security features. Some are built-in and always enabled. Others are optional because they aren\u2019t always appropriate, or because they\u2019re inconvenient for development. For example, forcing HTTPS may not be suitable for all websites, and it\u2019s impractical for local development.<\/p>\n Performance optimizations are another category of trade-offs with convenience. For instance, caching is useful in production, less so for local development. Error reporting needs are also widely different. The following checklist includes settings that:<\/p>\n\n
Deployment checklist<\/h3>\n