Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

psmail's avatar

Does Forge run OK on a DigitalOcean 512Mb instance

Hi.

I stumbled across this turn of phrase on the DigitalOcean help wiki -

Heads Up: If you're installing Laravel on DigitalOcean's 512MB VPS, make sure you add a swapfile to Ubuntu to prevent it from running out of memory ...

You'll find that here - https://www.digitalocean.com/community/tutorials/how-to-install-laravel-with-nginx-on-an-ubuntu-12-04-lts-vps

Anyhow, my question is in three parts - - Is this article on DigitalOcean correct? - Does Forge do this for you when setting up a DigitalOcean instance of 512Mb? - What is the general experience of those on a 512Mb Forge instance?

In my instance, I currently run my production server on a 1Gb instance. I don't get stacks of hits today ... certainly fewer than a thousand, within the space of about four hours, usually. This works out to about a hit every 14 second or so - i.e. not intensive at all.

Many thanks

0 likes
11 replies
omega's avatar
omega
Best Answer
Level 5

Works fine.

Just add this script as recipes and execute it on desired machine.

if [ -f /swapfile ]; then
 echo "Swap file already exists."
else
 sudo fallocate -l 1G /swapfile
  sudo chmod 600 /swapfile
  sudo mkswap /swapfile
  sudo swapon /swapfile
  echo "/swapfile none swap sw 0 0" >> /etc/fstab
  echo "vm.swappiness=30" >> /etc/sysctl.conf
  echo "vm.vfs_cache_pressure=50" >> /etc/sysctl.conf
  echo "Swap created and added to /etc/fstab for boot up."
fi
13 likes
bashy's avatar

It's mainly the RAM taken up by composer, but setting swap so it uses HDD/SSD, it will work.

1 like
mantasmo's avatar

Yea I do that on some dev instances when running "composer update". Not a big deal really.

ross.edman's avatar

Agreed with @bashy the only problems I have run into is Composer eating up the memory. I setup a Forge Recipe and just set up swaps on my demo servers. Here is the tutorial here and here is my recipe:

sudo dd if=/dev/zero of=/swapfile bs=1024 count=256k
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
sudo chmod 0600 /swapfile
davidfaux's avatar

I've been running a few sites on a 512 instance with no errors at all.

The trick to is to to commit the composer.lock file to your repository (make sure it isn't being excluded in .gitignore) and then using "composer install" in place of "composer update".

This not only ensures you have the exact same tested dependancies installed as you do in your development environment it also significantly decreases the amount of memory composer uses compared to an update run. I haven't experienced memory errors since doing this.

This is generally a good idea for all production servers, not just a 512MB instance btw :)

psmail's avatar

@omega - while I kind of knew most of what you highlighted (the links I included show this is the case) the way that you wrapped it up nicely into a recipe and added it to fstab so it is in play even after a reboot ... well that is pretty nifty. Hence, it is the answer to my question. Many thanks.

Cederman's avatar

Since the gc_disable() commit to Composer it now uses even less memory and is a lot faster :)

Please or to participate in this conversation.