So, I'm enjoying using the hackathon Magento Composer installer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using DeployHQ, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.

My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.

When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).

So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?

Any answers would be greatly appreciated.

  • 4
    I'm voting to close this question as off-topic because it is about Composer.
    – mbalparda
    Jan 22, 2015 at 16:41
  • 1
    Hi, specifically, it's related to using Magento with composer, and more specifically the Magento hackathon functionality. So I think you've been somewhat premature on that sorry! Jan 22, 2015 at 16:45
  • It is really complex to explain, but i'll try: since I think this question is not related to Magento and you do think it is, I marked it as Off topic. If a moderator or 4 other members decide it needs to be closed it will. If not, it will remain open. Message is automatic when you mark the question as off topic. And it is certainly off topic because the main topic is composer, tied to Magento but it can be applied to any other software installation and it might belong to a site about servers/deployments and not in Magento SE in my opinion.
    – mbalparda
    Jan 22, 2015 at 16:49
  • 1
    Guys, this question has received 2 up votes and a favourite. Surely allowing someone to answer this question can do no harm? It WILL HELP others in the MAGENTO community Jan 25, 2015 at 11:36
  • @JamesAllwood how did you go with this? Jan 28, 2015 at 22:28

3 Answers 3


I have set up a structure at our agency that allows us to use Composer to deploy all our Magento sites. This might be a bit of overkill for the question you asked but here's a basic overview of the structure anyway:

Repository structure

Below is the folder structure of the 'parent' repository. It contains the composer JSON and lock files and other configuration required for deployment.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock
  • All client-specific customisations are stored in a separate "customisations" module that gets installed using Composer
  • The Magento core is included as a Git submodule (code/magento)
  • A custom index.php and other folders like media and errors sit inside a public folder outside of the Magento root
  • Environment specific files (local.xml, robots.txt, etc) get symlinked into the Magento root during the deployment process
  • The vendor folder is excluded from Git, but the composer.lock file is included.


  • We deploy using Capsitrano which allows for multiple app servers and environments (staging/production)
  • Capistrano builds the entire codebase on the server in a new folder, and then swaps the webroot symlink at the very end meaning there is no downtime for your website.
  • Capistrano runs composer install during the build and deploys all modules into the Magento submodule.

This is still not a continuous integration setup but I find it works well for Magento sites. Feel free to send me a message if you'd like some more advice that's specific to your setup.

  • 1
    it's and old answer, but hope you can answer it. 1 Isn't storage of production local.xml a security issue? 2 At what stage and how do you import the database?
    – MployBy
    Jun 24, 2018 at 10:00

Another method is to use the magento hackathons copy deploy strategy, which kinda looks like this in your composer.json file:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true

Using above method copies the installed files from vendor to the actual installation, allowing it to be committed in Git and deployed as per normal, without having to do any composer install.

I'm not a big fan of pulling from third-party repositories when you're about to do a live deployment, and being dependent on third-party repositories is kinda risky, unless you've got some kind of proxy cache for your network.

Read this article and it'll give you a different perspective: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Basically, NPM went down (sort of..) and everyone's build systems stopped working (for critical deployments!) because they were directly depending on NPM. (NPM is kinda like Packagist for Javascript, except that NPM actually hosts the file and Packagist just points to the Github repos of modules - correct me if I'm wrong)

edit: just red fschmengler's response.. This is an elaboration on his 1st approach


It is important to understand that Composer is not a deployment tool, but a development tool.

There are different approaches how to prepare a deployment with all dependencies:

  • commit the vendor directory (or wherever composer installs the sources) to the project repository
  • use a build server that runs composer install and creates an archive with the result, which you can deploy repeatable to different target systems
    • running composer install on the server and then switch symlinks as suggested by @jharrison.au is a variation of this one

That aside, I don't recommend using composer for every single module and only keep composer.json and composer.lock in the project repository. This is overdoing it and makes development needlessly complicated. It makes perfect sense for code that is reused over several projects but why would you put project specific code into separate repositories?

My current project structure looks like this (using the alternative composer installers by AOE):

  • src contains all project specific modules. Composer also installs any other Magento modules here
  • .modman links to src so that modman can handle the symlinking easily
  • www is the webroot. Composer installs the Magento core here

This way I include external modules in the repository. If you prefer not to do so, adjust it like this:

  • src contains all project specific modules. To include them in .modman so that modman creates symlinks, use modman link
  • .modman is in .gitignore. Composer installs Magento modules here
  • www is the webroot. Composer installs the Magento core here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.