Member Avatar for jithinjohny

Hi,

Previously I have worked on codeigniter Framework. Since codeigniter developers are not even sure about version 3.0 , I decided to work with a better/new framwork.

The problem is, whichever the Framework I choose, it needed Composer to work on. First I choose laravel, then symfony , later cakephp. But usually in shared hosting services, they won't allow to install composer.

What is the better option I have ?

  • 2 Contributors
  • 2 Replies
  • 286 Views
  • 5 Hours Discussion Span
  • Latest Post Latest Post by jithinjohny

Dani AI

Generated

Composer is the PHP dependency manager — it pulls libraries, generates the autoloader and pins versions through composer.lock. Laravel relies on Composer-managed packages, but a shared host does not need Composer installed to run an app as long as the built vendor folder and autoload files are deployed.

Building on 's local-development idea, a practical workflow that works on most shared hosts:

  • Do all Composer work on a local/dev machine. Commit composer.json and composer.lock.
  • Produce a production-ready vendor set with: composer install --no-dev --optimize-autoloader --prefer-dist.
  • Deploy the project root plus the vendor folder to the host (FTP/SFTP/Git). Avoid running composer update on the live server — rely on composer.lock for reproducible installs.

If SSH/CLI is available on the host, running Composer there (or uploading composer.phar and invoking it) is cleaner; if not, local-build-and-upload is acceptable. Check that the server PHP version and required extensions match the local environment, and ensure storage/bootstrap cache directories are writable. Any Artisan tasks that must run (caches, migrations) should be executed via SSH when possible or handled as part of the deployment build.

For small projects the local-build + FTP approach is fine; for larger projects, prefer a host with SSH/Composer support or a CI/CD pipeline that builds artifacts and deploys them. Committing composer.lock and using composer install for production avoids unexpected version drift and keeps Laravel usable on shared hosting.

Recommended Answers

All 2 Replies

Member Avatar for Member #120589

You may be better to use composer on local machine and only upload updated/new files when it works locally. You don't want to be messing about with composer on a live site, do you?

I use laravel extensively (almost exclusively), albeit v4.2, and have shared hosting for most client projects. I've not hit a problem yet.

All my sites are developed locally (XAMPP on Win8.1) and FTPed using Filezilla.

I have variations where I have a few remote dev servers, GIT repos etc, but for most sall-scale projects, I don't think I really need anything else.

Edited by Member #120589
Member Avatar for jithinjohny

hello diafol,

Thank you for your reply. Actually i was not having any idea on what composer does. So i thought it is essential in running/executing a project developed in laravel. That's why I askied the question.Now I am going ahead with Laravel.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.