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

gkuschnik's avatar

Sessions eating up storage. What now?

Hi,

I am lost. I need your help...

I host a Laravel 5.2 application via Forge on Digital Ocean and run into an issue with scaling. I have no experience with DevOps and just received a warning from new Relic that 90% of my 40GB of storage is consumed. I have 1 more month until it's completely full. Digital Ocean does not offer to increase the Droplet's storage above 40GB.

Running du -h | grep '[0-9.]+G' on the server shows that most of the storage is consumed by session files in /storage/framework/session.

The application uses the file session driver with the expiry set to 9 months - reducing the expiry (and thus forcing users to log in again) is not an option.

What is my best choice? What would be good practise and still work if the project grows by another 10x?

  • Should the file session driver only be used for small projects? If yes, which driver can be recommended? Database? The project uses MySql as DB. Does Laravel allow for a separate database connection for sessions? Or should I set up a separate (MySQL) database? Where? AWS? As mentioned - I have no experience with DevOps.

  • Digital Ocean offers to add "Block Storage" to the server - should I simply attach that storage and copy all files over? As I understand the block storage will be added as a new partition - can the session.files config point to another partition?

  • Is there any good website on the topic of scaling / DevOps for beginners? I feel like the standard Forge setup might not be sufficient anymore for the project very soon.

Thank you so much for your help! It is super appreciated!!

Best, Gerhard

0 likes
2 replies
bheath's avatar

At first glance, I think a better understanding of why your sessions are so big and why the requirement for storing them for 9 months? This on face value seems really odd and dangerous, and perhaps you are doing something wrong there.

Do you have a requirement to port these sessions to the new solution?

Do you have any idea how big an individual session is? This is a factor on which session storage you can use as some have limits on their entry size.

Depending on these answer Redis would probably be a better solution as it's scalable.

You can use mysql for sessions. I am not sure off hand if out of the box you can use a different driver/connection on just sessions. If not that's probably easy to get around that by creating a custom session driver that extends the mysql one.

A quick possible solution would be to spin up a new dropplet and move everything over to it.

I don't know if there is a good devops site that would address your specific problem. There are plenty of devop consulting firms out there that would assist you on this matter.

Cronix's avatar

You could always add a 2nd server and have it used exclusively for the db, and switch sessions to use the db. Now you can easily scale your webserver, as well as the db server, and have a lot more room on each. This is generally better than having everything on a single server anyway, especially for larger applications. DB has it's own dedicated hd, cpu, ram, etc., and so does the webserver. It will be faster as well (assuming both servers are in the same datacenter). And yes, you can do all of that within forge.

Please or to participate in this conversation.