Download the PHP package philipstuessel/deploy-machine without Composer
On this page you can find all versions of the php package philipstuessel/deploy-machine. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download philipstuessel/deploy-machine
More information about philipstuessel/deploy-machine
Files in philipstuessel/deploy-machine
Package deploy-machine
Short Description Deploy any project to any server you can SSH into, and roll it back in a second. One bash script, one config file.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package deploy-machine
deployMachine
Deploy any project to any server you can SSH into, and roll it back in a second. One bash script, one config file, nothing else.
Install
It is the same script either way — take it however your project already gets its tools.
npm
Composer
The commands in this README call it as .deploy/deployMachine.sh. Installed as
a package, only that first word changes:
| Installed with | call it as | more |
|---|---|---|
| npm | npx deploy-machine |
NPM.md |
| Composer | vendor/bin/deployMachine.sh |
COMPOSER.md |
The config
Everything it needs to know sits in one file:
That is a complete deployment. Nothing else is required.
What happens on the server
Every deploy creates a new folder, then moves one symlink:
Going live is a symlink move, so it is instant. Going back is the same move in reverse — which is why a rollback takes no time at all, however big the project.
current can also live inside releases/ — see
examples/current-in-releases.json.
The five commands
status looks like this — cu is live, re are the ones you can go back to:
rollback="20260831191920" jumps to a specific one. There is --help and
--version too.
Everything is a key
Every setting is a key="value". Either in the JSON under vars, or on the
command line — and the command line wins:
That is how CI hands over the private key that must not live in the repo:
A typo like dryrun="true" stops the run instead of quietly deploying.
Your own steps
Without steps it does the usual thing: upload, switch, clean up. When you need
more, write it out:
{{name}} drops in a value from the config. There are five types:
| Type | what it does |
|---|---|
run |
a command, on: local here or remote there |
upload |
push files over |
symlink |
point a link somewhere else |
healthcheck |
call a URL until it answers |
cleanup |
delete old releases |
If a step fails, everything stops there. If the symlink had already moved, it moves back on its own — a half-finished deploy never stays behind.
In a pipeline
GitLab:
GitHub:
Only bash has to be there. rsync, ssh, jq and curl install themselves
if they are missing.
Worth knowing
Keys come as a file (ssh_key_file) or as content (ssh_key, for CI). Values
whose key name sounds like a secret show up as *** in the log.
The host key is looked up in your ~/.ssh/known_hosts when you say nothing.
If it is not there, it asks the server — and tells you that this is unverified.
Without host it deploys locally with rsync into a folder. Handy for
trying things out.
A deploy log on the server: log="true" appends one line per deploy and
rollback, with a timestamp, to deploy.log in deploy_path.
A lock on the server keeps two deploys from running into each other: the
second one stops and says who holds it. A lock that a killed run left behind
expires after lock_timeout minutes (30), or goes away with unlock.
lock="false" turns it off.
Every setting is in --help. There are more than shown here, but you rarely
need them.
Ready-made configs are in examples/ — from the three-line minimum to one that shows every setting at once.
License
MIT — see LICENSE.
