Add a repo
Head to the Deployments tab of your site in Moss and click Add to associate a git repo with your site.
Select the provider where your git repo is hosted. In case you choose one of the providers Moss natively supports (GitHub, GitLab and Bitbucket) you must select the corresponding user, repository, and branch.
If your repo is on any other provider, choose Custom and tell Moss the corresponding repository URL and branch. If such repository is private, you must manually upload the given deployment key to authorize Moss deploy your repo on your servers. Note that in this case the push-to-deploy feature isn't available.
Click Add and Moss will start an operation to update your git repo in the background.
Set up persistent paths if needed
If your application needs files or folders that don't belong to the repo, e.g. application secrets or user-generated content, you can set such persistent paths here.
We say such paths are persistent because they're shared across deployments. I.e. a new deployment won't overwrite their content since, by definition, they're not part of the git repo.
In this example you can see that the current release of a Laravel application links the
.env file and the
storage folder to their corresponding file/folder within the
shared/ directory. Such links are created during a deployment according to your persistent path settings. If you need to upload some content to your site, do it onto the corresponding path in the
Edit your deployment flow if needed
Click Deployment Flow and review the steps Moss takes to deploy your new release.
Moss supports zero-downtime deployments by allowing you to specify both pre-activation and post-activation scripts. Whatever you include within the pre-activation script will be run before your new release activates. During that time your previous release is the one being served by the web server. Moss automatically creates an appropriate script for natively supported frameworks, but you can fine-tune it at will. Such script usually updates your app's dependencies (e.g. via composer in a PHP app) and runs your database migrations (e.g. via artisan in a Laravel app).
Once this script ends successfully the new release activates and becomes available to your users. At that moment, you may want to run a post-activation script to run commands that depend on the new version of your code. E.g. Moss suggests a simple script to restart your workers in a Laravel application (just in case you're using workers at all). If you don't need to run anything at this stage, just provide an empty script.
Note for Node.js applications: Moss automatically restarts your Node processes using pm2, so you don't need to add the corresponding command in your post-activation script. Given this mandatory step in the post-activation phase, your site could have a short downtime: Just the time your app requires to start.
Deploy your site
Finally deploy your site by means of any of this options:
- Click Deploy; or
- Enable Push to deploy - and push your repo to the appropriate branch afterwards