You have two options.
- Commit the entire project with Git.
- Use Acquia BLT.
The first method is not preferred because it makes the repository size massive and unwieldy, but if you have no build server you have no build server. But not having a build server isn't necessarily the end, because...
The second choice would allow you to build locally and deploy to remote using a command BLT provides.
Here is an example. I want to build my develop branch and put it on the server. I can enter the repository url in my project.yml file (provided by BLT), and run this command:
blt deploy -Ddeploy.branch=develop-build -Ddeploy.commitMsg='PROJECT-000: Generating new build for PROJECT.'
This will generate a build artifact (which is not committed into your canonical repository), but instead committed to the remote repository being deployed to as develop-build
or whatever you name the branch. You then switch your dev environment to run that branch instead of develop
. For instance, my canonical repo lives on GitHub, my remote repo is on Acquia. GitHub won't ever have the -build
branches committed to it, and the Acquia repo won't ever have develop
or master
- it will have the build artifacts of deployed branches. You could use the same repository for both, but its a drag IMO because you (or I, anyway) want the canonical repo to be clean and not be dragging around artifacts of this size.
It is easier with a CI server to automate all of this, but Acquia BLT is a viable option when you don't have a CI service to use because you can run the commands yourself from your machine.
Another option would be to build your own scripts to do this as well, but I'd say you are better off starting with BLT. It can be added to existing projects, and it is straight-forward to configure via project.yml.
So no, you do not need to run Composer on the production server. Most hosting companies would never allow this anyway.