<p>Entirely possible. There is some discussion of having Craft installed in a load-balanced environment <a href="https://craftcms.stackexchange.com/questions/4719/load-balancing-nodes-configuration-3-craft-nodes-behind-f5-big-ip">here</a>.</p>

<p>You'll want to have CRAFT_STORAGE_PATH point to a shared file system for all servers.</p>

<p>If you have sticky sessions enabled at a load-balancer level, then PHP sessions won't be a problem.  If not, then you'll want to set <a href="http://buildwithcraft.com/docs/config-settings#overridePhpSessionLocation" rel="nofollow noreferrer">overridePhpSessionLocation</a> to true and have the PHP session files saved on the same shared file system.</p>

CC BY-SA 3.0
2015-04-04T17:46:43.277Z
2015-04-04T17:46:43.277Z
2017-04-13T12:50:59.930Z
Brad Bell
<p>Along with Brad's helpful answer, I can certainly verify that the "Pro" level of Craft does support S3 perfectly. If you implement that for all your assets, and then track any other site/template code and graphics in something like Git, you can easily roll out an auto-scaling group in EC2 that could expand dynamically with traffic, behind an ELB.</p>

<p>Just be sure that when a new instance is spun up you use something like the user-data field to initiate a bootstrapping script to <code>git pull</code> and sync up the new instance with any changes to the current repository.</p>

CC BY-SA 3.0
2015-12-29T15:31:26.693Z
The *only* shortcoming i've seen yet of a scaling fleet of EC2 instances is that user profile pictures (Craft users) are stored on the localhost and cannot replicate out across instances. I've seen in another thread that this issue is likely going to be addressed in 3.0+.
Neal Magee
CC BY-SA 3.0
2015-06-08T11:19:02.260Z
2015-06-08T11:19:02.260Z
Neal Magee
<p>We are looking at Craft as our CMS but would love to be able to scale the installation across multiple Amazon EC2 instances.</p>

<p>Is this possible? </p>

<p>Can all assets uploaded to Craft be pushed to S3? </p>

<p>Is there any other data (eg sessions) that are stored on local storage that would likely cause a problem?</p>

<server><s3>
Can Craft easily be hosted across multiple servers?
# Can Craft easily be hosted across multiple servers?

(Asked by: username_0 on 2015-04-04)

We are looking at Craft as our CMS but would love to be able to scale the installation across multiple Amazon EC2 instances.

Is this possible?

Can all assets uploaded to Craft be pushed to S3?

Is there any other data (eg sessions) that are stored on local storage that would likely cause a problem?

**Tags:** server, s3


---

## 2 answers

### Answer by username_1 on 2015-04-04. Score: 5

Entirely possible. There is some discussion of having Craft installed in a load-balanced environment [here](https://craftcms.stackexchange.com/questions/4719/load-balancing-nodes-configuration-3-craft-nodes-behind-f5-big-ip).

You'll want to have CRAFT\_STORAGE\_PATH point to a shared file system for all servers.

If you have sticky sessions enabled at a load-balancer level, then PHP sessions won't be a problem. If not, then you'll want to set [overridePhpSessionLocation](http://buildwithcraft.com/docs/config-settings#overridePhpSessionLocation) to true and have the PHP session files saved on the same shared file system.


---

### Answer by username_2 on 2015-06-08. Score: 1

Along with Brad's helpful answer, I can certainly verify that the "Pro" level of Craft does support S3 perfectly. If you implement that for all your assets, and then track any other site/template code and graphics in something like Git, you can easily roll out an auto-scaling group in EC2 that could expand dynamically with traffic, behind an ELB.

Just be sure that when a new instance is spun up you use something like the user-data field to initiate a bootstrapping script to `git pull` and sync up the new instance with any changes to the current repository.

> **Comments:**
> **username_2**: The *only* shortcoming i've seen yet of a scaling fleet of EC2 instances is that user profile pictures (Craft users) are stored on the localhost and cannot replicate out across instances. I've seen in another thread that this issue is likely going to be addressed in 3.0+.  

---

