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

NancyJames's avatar

Multiple Laravel Projects on the same Server

Is there a best practice way to handle multiple laravel projects on the same server?

We have VPS with fixed resource limits currently hosting about 7 sites that I'd like to convert to Laravel but we'd very quickly run out of space when the vendor folder is 1+ GB (on the site I'm working on currently its 3GB, not sure why this one is so much bigger since I did it without a starter kit and I only added a couple of small libraries for vue and date-fns) That's a lot of extra space needed for duplicated code

0 likes
11 replies
LaryAI's avatar

Certainly! Here are some best practices and solutions for hosting multiple Laravel projects on the same server, especially when concerned about disk space due to duplicated vendor directories:

1. Shared Vendor Directory (Advanced)

You can share a single vendor directory among multiple Laravel projects, if they all use the same Laravel version and dependencies. This is tricky and not always recommended, but possible with symlinks.

Steps:

  1. Create a common directory for your shared dependencies, e.g., /var/www/laravel-shared/vendor.

  2. Install your dependencies there using Composer.

  3. In each Laravel project, remove the local vendor directory and create a symlink:

    rm -rf /var/www/project1/vendor
    ln -s /var/www/laravel-shared/vendor /var/www/project1/vendor
    
  4. Do the same for the composer.lock and composer.json if you want to keep everything in sync.

Caveats:

  • All projects must use the exact same dependencies and versions.
  • Updates to one project’s dependencies will affect all others.

2. Optimize Vendor Size

  • Use composer install --no-dev in production to avoid installing unnecessary development packages.
  • Use composer install --optimize-autoloader to optimize the autoloader.
  • Audit your composer.json for unused packages.

3. Docker or Containers

Consider using Docker containers for each project. This isolates dependencies and can help with resource management, though it may not save disk space if each container has its own vendor directory.

4. Symbolic Links for Common Packages

If you have custom packages or libraries used by all projects, you can symlink just those packages in the vendor directory.

5. Disk Space Management

  • Regularly clean up old logs (storage/logs).
  • Use tools like du and ncdu to find large files/directories.
  • Consider moving storage (logs, cache) to a separate partition if possible.

Summary:
The only safe way to share a vendor directory is if all projects have identical dependencies. Otherwise, optimize your dependencies and clean up unused packages. For most teams, keeping separate vendor directories is the safest, but you can reduce their size with Composer options.

Example: Production Composer Install

composer install --no-dev --optimize-autoloader

Symlink Example:

ln -s /var/www/laravel-shared/vendor /var/www/project1/vendor

If you need more details on any method, let me know!

vincent15000's avatar

I'm not sure that it's a good idea to share the vendor folder, because if one website is down for some unknown problem with the dependencies, all websites will be down.

Glukinho's avatar

Can you post your composer.json? It's interesting what dependencies can eat 3 Gb.

I also wouldn't share vendor folder among projects, you definitely will face huge problems with updates even if you force your 7 sites to use the same dependencies. Better buy more space on your VPS.

ian_h's avatar

It sounds like you've possibly outgrown your VPS tbh and would be better off with something from the likes of Hetzner or DigitalOcean where you'd have some more freedom.

I'd say there's an issue with your dependencies too. I currently have a local copy of our cyber security application on this laptop and it's a fair sized app that started as a Laravel 7 project and now upgraded to Laravel 11, and the vendor dir is 206MB. I'd start by looking at what's causing such a huge amount of storage usage in there.

Check your composer.json file for the following entry in the config {} section, if it's not there, I'd suggest adding it:

"preferred-install": "dist",

This will preferably only pull package dependencies from the required section and ignore the required-dev section, which recursively, through the dependency chain, could result in a substantial difference.

Definitely also follow @vincent15000 's advice and don't share dependencies.. you could find that catastrophic later down the road with version mismatches.

Cheers..

Ian

1 like
Snapey's avatar

Your vendor folder should be nothing like that size.

A recent Laravel 12 project with a couple of extra packages is only 112Mb.

I would delete the vendor folder and re-install with composer install

Snapey's avatar

also check your php-zip extension is installed and up to date.

NancyJames's avatar

@Snapey ah composer was complaining about that, but shouldn't the files be unzipped anyway?

This is my composer.json

{ "$schema": "https://getcomposer.org/schema.json", "name": "laravel/laravel", "type": "project", "description": "The skeleton application for the Laravel framework.", "keywords": [ "laravel", "framework" ], "license": "MIT", "require": { "php": "^8.2", "laravel/framework": "^12.0", "laravel/tinker": "^2.10.1" }, "require-dev": { "fakerphp/faker": "^1.23", "laravel/pail": "^1.2.2", "laravel/pint": "^1.13", "laravel/sail": "^1.41", "mockery/mockery": "^1.6", "nunomaduro/collision": "^8.6", "phpunit/phpunit": "^11.5.3" }, "autoload": { "psr-4": { "App\\": "app/", "Database\\Factories\\": "database/factories/", "Database\\Seeders\\": "database/seeders/" } }, "autoload-dev": { "psr-4": { "Tests\\": "tests/" } }, "scripts": { "post-autoload-dump": [ "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump", "@php artisan package:discover --ansi" ], "post-update-cmd": [ "@php artisan vendor:publish --tag=laravel-assets --ansi --force" ], "post-root-package-install": [ "@php -r \"file_exists('.env') || copy('.env.example', '.env');\"" ], "post-create-project-cmd": [ "@php artisan key:generate --ansi", "@php -r \"file_exists('database/database.sqlite') || touch('database/database.sqlite');\"", "@php artisan migrate --graceful --ansi" ], "dev": [ "Composer\\Config::disableProcessTimeout", "npx concurrently -c \"#93c5fd,#c4b5fd,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"npm run dev\" --names='server,queue,vite'" ], "test": [ "@php artisan config:clear --ansi", "@php artisan test" ] }, "extra": { "laravel": { "dont-discover": [] } }, "config": { "optimize-autoloader": true, "preferred-install": "dist", "sort-packages": true, "allow-plugins": { "pestphp/pest-plugin": true, "php-http/discovery": true } }, "minimum-stability": "stable", "prefer-stable": true }

NancyJames's avatar

I just did an analysis and my Sebastian folder is 1.2gb, PHP Unit is 600mb and Laravel is nearly 500mb, on my new computer where everything works right and is shiny and new those folders are <30mb combined heh. So I guess it probably is that zip warning

martinbean's avatar

@nancyjames Doesn’t sound like a very good VPS if they’re then imposing such disk space limits. But, as others have said, a 1 GB+ vendor directory is massive. I’ve just calculated the vendor folder size for one of my more mature projects and it’s only 171 MB.

In regard to the subject of your question, what are the seven sites on this VPS? Are they related in some way? Are they sites that can be rolled up and served from a single application using a multi-tenancy approach, rather than re-building seven sites as seven Laravel applications?

jlrdw's avatar

A couple years ago I had 4 sites on the same server, but just doing some testing.

You place main laravel one level higher than the web folders.

Nginx conf I had

laravel859 was public inside www, another folder laravel859up housed main laravel files. one level higher than www.

However for a real production site and as others has said, I would not recommend doing this.

Please or to participate in this conversation.