Packaging cleanups, reinstate generated files for the tarball
[rainbows.git] / DEPLOY
blob253a06827040270b517ad227f6e3bf529547d35f
1 = Deploying \Rainbows!
3 == \Rainbows! only
5 For the daring, you should consider deploying \Rainbows! in a standalone
6 configuration.  This will be more highly recommended as \Rainbows!
7 stabilizes, especially if static file performance improves (or you don't
8 need them).
10 You will need to do this to support things like BOSH or do real-time
11 processing of the request body as it is being uploaded.
13 In this case, haproxy or any similar (non-request-body-buffering) load
14 balancer should be used to balance requests between different machines.
16 == nginx proxying to \Rainbows! or Unicorn
18 For high-traffic applications, routing slow actions to \Rainbows! with
19 nginx is recommended as nginx can serve static files faster and nginx
20 can forward fast actions to Unicorn.
22           static files
23             |
24       nginx |--> slow actions --> Rainbows!
25             |
26             `--> fast actions --> Unicorn
28 Be sure to set <tt>proxy_buffering off</tt> in nginx for "slow actions"
29 if you have Comet applications (but not for Unicorn).
31 == Denial-of-Service Concerns
33 Since \Rainbows! is designed to talk to slow clients with long-held
34 connections, it may be subject to brute force denial-of-service attacks.
35 In Unicorn and Mongrel, we've already enabled the "httpready" accept
36 filter for FreeBSD and the TCP_DEFER_ACCEPT option in Linux; but it is
37 still possible to build clients that work around and fool these
38 mechanisms.
40 \Rainbows! itself does not feature any explicit protection against brute
41 force denial-of-service attacks.  We believe this is best handled by
42 dedicated firewalls provided by the operating system.