<p><strong>No reason at all, that should work perfectly fine.</strong></p>

<p>In fact, at least 90% of my projects keep files, database, and assets all on the same server. For the remaining 10%, I'm usually only moving the assets to Amazon S3. Everything else continues to live on the same server.</p>

CC BY-SA 3.0
2017-04-12T22:52:31.197Z
Amazon S3 is really convenient indeed. Especially for moving around the site between servers if it's big, and for backups. Gives alot less headaches.
tom
CC BY-SA 3.0
2017-04-12T17:59:09.873Z
2017-04-12T17:59:09.873Z
Lindsey D
<p>Not to stray too far off the Craft beaten path here but any scaling guidelines you see on other sites usually will apply to Craft as well. You'll know when you need to start scaling... might you have a ton of entries and the database is starting to slow down. Or you've outgrown your small VPS. It happens. Or least that's what you hope to have happen!</p>

<p>Unless you get a ton of traffic or are doing some crazy database calls, even a single, small VPS with everything you've described properly setup should be able to handle a good amount of visits per month (at least 1 million, if you can cache, you can easily do more than that).</p>

<p>When you have to scale, you've probably either run out of disk space/your site otherwise grows or you get website traffic (visitors) and your server simply can't keep up any more. Knowing which boat you're in will help you figure out what to do next.</p>

<p>Keep 20-30% of your disk space available. When you hit that limit, think about scaling. At least on a VPS, you can usually "resize" your limits fairly easily or attach more storage with some providers.</p>

<p>As far as Craft is concerned, if you have plenty of space left, but you're getting more visitors, it's super easy to start serving your static files from a CDN and/or S3 just by changing some settings inside Craft. That'll cut your load on your server too.</p>

<p>If you're not strapped for disk space, most people spin off their database to another server first for performance reasons.  When MySQL gets a lot of room to play around in, it tends to run faster. </p>

<p>There's some schools of thought that if you want to be truly be PCI Compliant (for doing e-commerce), your database should live on a separate server as well. (That's really up your QSA.)</p>

<p>When you outgrow that, you might run a load balanced server setup (meaning 2 or more web servers), you usually have those servers each hit that one database.  Or you can duplicate the whole server to increase redundancy (since if your single db goes down, you're SOL.)</p>

<p>There's pros and cons to all approaches but if you know you're going to get big eventually, it helps to have a little overview.</p>

CC BY-SA 3.0
2017-04-12T23:06:43.873Z
2017-04-12T23:06:43.873Z
RitterKnight
<p>Is there any reason the mySQL, CraftCMS, and assets/images/content can't all live on the same server, assuming the server is appropriately sized and backed up?</p>

<p>Are there any sizing/scaling guidelines?</p>

<assets><database><server>
Self-hosting requirements/scaling
# Self-hosting requirements/scaling

(Asked by: username_0 on 2017-04-12)

Is there any reason the mySQL, CraftCMS, and assets/images/content can't all live on the same server, assuming the server is appropriately sized and backed up?

Are there any sizing/scaling guidelines?

**Tags:** assets, database, server

---

## 2 answers

### Answer by username_1 on 2017-04-12. Score: 5

**No reason at all, that should work perfectly fine.**

In fact, at least 90% of my projects keep files, database, and assets all on the same server. For the remaining 10%, I'm usually only moving the assets to Amazon S3. Everything else continues to live on the same server.

> **Comments:**
> **username_2**: Amazon S3 is really convenient indeed. Especially for moving around the site between servers if it's big, and for backups. Gives alot less headaches.  

---

### Answer by username_3 on 2017-04-12. Score: 3

Not to stray too far off the Craft beaten path here but any scaling guidelines you see on other sites usually will apply to Craft as well. You'll know when you need to start scaling... might you have a ton of entries and the database is starting to slow down. Or you've outgrown your small VPS. It happens. Or least that's what you hope to have happen!

Unless you get a ton of traffic or are doing some crazy database calls, even a single, small VPS with everything you've described properly setup should be able to handle a good amount of visits per month (at least 1 million, if you can cache, you can easily do more than that).

When you have to scale, you've probably either run out of disk space/your site otherwise grows or you get website traffic (visitors) and your server simply can't keep up any more. Knowing which boat you're in will help you figure out what to do next.

Keep 20-30% of your disk space available. When you hit that limit, think about scaling. At least on a VPS, you can usually "resize" your limits fairly easily or attach more storage with some providers.

As far as Craft is concerned, if you have plenty of space left, but you're getting more visitors, it's super easy to start serving your static files from a CDN and/or S3 just by changing some settings inside Craft. That'll cut your load on your server too.

If you're not strapped for disk space, most people spin off their database to another server first for performance reasons. When MySQL gets a lot of room to play around in, it tends to run faster.

There's some schools of thought that if you want to be truly be PCI Compliant (for doing e-commerce), your database should live on a separate server as well. (That's really up your QSA.)

When you outgrow that, you might run a load balanced server setup (meaning 2 or more web servers), you usually have those servers each hit that one database. Or you can duplicate the whole server to increase redundancy (since if your single db goes down, you're SOL.)

There's pros and cons to all approaches but if you know you're going to get big eventually, it helps to have a little overview.


---

