PHPackages wearebase/base-bash-bosh - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [DevOps & Deployment](/categories/devops) 4. / 5. wearebase/base-bash-bosh AbandonedArchivedLibrary[DevOps & Deployment](/categories/devops) wearebase/base-bash-bosh ======================== B.O.S.H is a collection of orchestration & synchronisation scripts which can be used to deploy pre-built code and synchronise or backup databases and assets v1.0.27(10y ago)81.4k2[4 issues](https://github.com/wearebase/base-bash-bosh/issues)ProprietaryShell Since Jan 2Pushed 10y ago11 watchersCompare [ Source](https://github.com/wearebase/base-bash-bosh)[ Packagist](https://packagist.org/packages/wearebase/base-bash-bosh)[ RSS](/packages/wearebase-base-bash-bosh/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependenciesVersions (26)Used By (0) Base Orchestration & Synchronisation Helper \[BETA\] ======================================================== [](#base-orchestration--synchronisation-helper-beta) B.O.S.H is a collection of orchestration & synchronization scripts which can be used to deploy pre-built code and synchronise or backup databases and assets. We built this as a tool to solve a problem, and it works great for us. However it has only been used with a small number of projects and as a result there maybe still be some bugs. We do not recommend its use on a production environment until it has been tested against a similar, non-production environment. If you find a problem please raise an issue for us. Prerequisites: -------------- [](#prerequisites) - You will need the following on your machine `sshpass` `git` ``` ubuntu: sudo apt-get install sshpass git ``` Installation ------------ [](#installation) Run the following commands (check for latest version) ``` composer require wearebase/bosh:~1.0.23 composer install ``` Install ------- [](#install) ``` ./bin/bosh install ``` No other commands can be run until your have run the install command. This copies the example configuration and environment files to the root of your project. Setup ----- [](#setup) Once installed, there will be a set a configuration files in the root of your project. `config/bosh-config` contains the key settings for the scripts. `config/environments/` contains `.env` files which are the *environments* the bosh scripts use as parameters. For example the `production` environment uses settings from the `config/environments/production.env` file. The environment `local` does not need a user/hostname/project-dir (see `config/environments/local.env` for an example). An example `config/environments` folder could contain ``` local.env vagrant.env development.env staging.env production.env ``` Install To Server ----------------- [](#install-to-server) Once you have made a configuration for a server, you can run the following command to setup the project directories on your server for deployments. See the Deploy step for more information on this. ``` ./bin/bosh install-remote ``` The script is called with one parameter. This is the name of the environment you wish to setup the folder structure on. It create the PROJECT\_DIR folder as defined in `config/environments/.env` and the folders required within it. General Usage ------------- [](#general-usage) From the command line, various scripts can be run in a similar way to the install scripts mentioned above do: ``` ./bin/bosh ``` ### Deploy [](#deploy) Builds (if a build script has been defined) and deploys commited code to a server ``` ./bin/bosh deploy ``` The script is called with two parameters. The first is the name of the environment you wish to deploy to. The configuration for which can be found in `config/environments/.env`. The second is the git hash, or a tag or branch name you wish to deploy. Only committed code will be deployed. #### What it does [](#what-it-does) Firstly, the code base will be cloned from git using your commits that you have made locally (instead of the remote git server). This clone will be placed in `./dist` temporarily This deploy script will call the build script (the location of which is defined in the `bosh-config` file. This location is local to the root of your project) to prepare the site for deployment. This means that dependencies, pre-compiled files, minified scripts and anything else not source controlled will all have been placed in the `./dist` directory alongside your source controlled code. If you wish to call a build script which is outside the project root, you will need to create a script inside which then proxies to the external script. This code will then be zipped, moved to the remote server and unzipped and placed into the releases folder under the timestamp it was deployed at. Any shared directories as defined in `shared-paths.sh` (for files which are not source controlled such as user uploads) will be symbolically linked into the release folder, and a symbolic link which points to the current release will be updated so that `current` now points to your new release. Within the `bosh-config` file there are arrays for `PRE_PUBLISH` and `POST_PUBLISH` commands which are run before the symbolic link `current` is updated and after. This is where unit tests and other checking tools will be run. If any of part of the script fails to pass the script will bail out. ##### Gotchas [](#gotchas) You must commit any code needed in the build. This includes the build script itself, eg. the Makefile. ### Sync Database [](#sync-database) This script will backup, copy and import databases from one server to another ``` ./bin/bosh sync-db ``` The script is called with two parameters. The first is the environment name you with to copy FROM. The second is also an environment name - the one you wish to copy the database TO. There is an optional parameter `-b` or `--backup` which will skip the import step. ~~You cannot sync to `production`. Update: You can now! It uses your local machine as a proxy. #### What it does [](#what-it-does-1) The export from the FROM server simply runs the `mysqldump` command and does an entire database dump. This file is then copied to the TO server you specified. The database will then be imported and apply the sql commands from the `POST_IMPORT_DB_COMMAND` item in the `bosh-config` file . These commands alter database values to turn the application into a development state from a production state, for example changing email addresses and sandboxing payment gateways. **Important note:** Cancelling the script does not stop any processes that are running on the remote. You will need to let these finish or kill them manually be logging into the remote server yourself. ### Sync Uploads (Wordpress Only) [](#sync-uploads-wordpress-only) Copies upload files from one server to another ``` ./bin/bosh sync-uploads ``` The script is called with two parameters. The first is the environment name you with to copy FROM. The second is also an environment name - the one you wish to copy the database TO. The location of the uploads folder may be different depending on your wordpress setup, so these locations must be defined in the corresponding environment file in `config/environments/` You cannot sync to `production`. You can only sync TO or FROM `vagrant` with `local` **Important note:** Cancelling the script does not stop any processes that are running on the remote. You will need to let these finish or kill them manually be logging into the remote server yourself. ### Health Score 33 — LowBetter than 75% of packages Maintenance10 Infrequent updates — may be unmaintained Popularity22 Limited adoption so far Community12 Small or concentrated contributor base Maturity73 Established project with proven stability Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~14 days Recently: every ~22 days Total 24 Last Release 3826d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/a450103bae0408522e011a167ba85c6f67ae325fe7ffcca894e86ab2487daccc?d=identicon)[wearebase](/maintainers/wearebase) --- Top Contributors [![dave1010](https://avatars.githubusercontent.com/u/50682?v=4)](https://github.com/dave1010 "dave1010 (2 commits)") --- Tags deployorchestrationbashsynchronisation ### Embed Badge ![Health badge](/badges/wearebase-base-bash-bosh/health.svg) ``` [![Health](https://phpackages.com/badges/wearebase-base-bash-bosh/health.svg)](https://phpackages.com/packages/wearebase-base-bash-bosh) ``` ### Alternatives [banago/phploy PHPloy - Incremental Git (S)FTP deployment tool that supports submodules, multiple servers and rollbacks. 1.4k47.2k](/packages/banago-phploy)[easycorp/easy-deploy-bundle The easiest way to deploy Symfony applications 468310.2k](/packages/easycorp-easy-deploy-bundle)[jalogut/magento2-deployer-plus Magento 2 deployment tool based on deployer.org 201415.5k](/packages/jalogut-magento2-deployer-plus)[hpatoio/deploy-bundle Easy deploy via rsync. Porting of Symfony 1 project:deploy command. 3696.6k1](/packages/hpatoio-deploy-bundle)[rafaelstz/deployer-magento2 Magento 2 deployment tool based on deployer.org 5223.5k](/packages/rafaelstz-deployer-magento2)[ngmy/webloyer Webloyer is a Web UI for managing Deployer deployments 2181.1k](/packages/ngmy-webloyer) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)