Connect Remote Git & Auto‑Deploy Node.js on Plesk

Running a Node.js application on a VPS or dedicated server is only half the battle – you also need a reliable way to pull code from a remote Git repository and deploy it automatically whenever you push changes. Plesk’s built-in Git extension makes this process straightforward, even if you’re not a command-line guru. In this guide, we’ll walk through connecting a remote repository (GitHub, GitLab, Bitbucket, etc.) to a Plesk domain, configuring a post-receive hook, and setting up an automatic build-and-deploy pipeline for a typical Node.js project.

1. Prerequisites

• A Plesk server with the Git extension installed (available in the Plesk Extension Catalog).
• A domain or sub-domain configured in Plesk that will host your Node.js app.
• Node.js installed on the server – Plesk can install the runtime for you via Tools & Settings > Updates and Upgrades > Add/Remove Components > Node.js.
• Access to a remote Git repository (GitHub, GitLab, Bitbucket, or a self-hosted Git server) with push rights.
• SSH key pair (optional but recommended) for password-less authentication between Plesk and the remote repo.

2. Adding the Remote Repository in Plesk

1. Log in to the Plesk panel and go to Websites & Domains > Git.
2. Click Add Repository and choose Remote Git repository.
3. Enter the repository URL (e.g., git@github.com:username/project.git for SSH or https://github.com/username/project.git for HTTPS).
4. If you use SSH, paste the public key that Plesk generated (or upload your own) into the remote service’s Deploy Keys section.
5. Select the target directory where the code should be checked out – typically /var/www/vhosts/example.com/httpdocs or a sub-folder like /var/www/vhosts/example.com/nodeapp.
6. Click OK. Plesk will clone the repository and display the latest commit.

3. Setting Up a Post-Receive Hook for Automatic Deployment

A post-receive hook runs on the server each time a new commit is pushed to the remote repository. We’ll use it to install dependencies, build the project (if you use a bundler like webpack or tsc), and restart the Node.js process.

3.1 Create the Hook Script

In the repository directory, create a file named post-receive (no extension). The script should be executable and contain the commands needed for your build.

Debian/Ubuntu (apt) – Example

# Navigate to the repository directory
cd /var/www/vhosts/example.com/nodeapp

# Ensure the script is executable
chmod +x post-receive

# Edit the script
nano post-receive

AlmaLinux/Rocky/RHEL (dnf) – Example

# Navigate to the repository directory
cd /var/www/vhosts/example.com/nodeapp

# Ensure the script is executable
chmod +x post-receive

# Edit the script
vim post-receive

Insert the following content (adjust paths and commands to match your project):

#!/bin/bash
# Change to the repository root
cd "$(dirname "$0")"

# Log the deployment (optional)
echo "$(date) – Deploy started" >> /var/log/plesk-git-deploy.log

# Install / update Node.js dependencies
/usr/local/bin/npm install --production

# If you have a build step (e.g., TypeScript compilation)
if [ -f package.json ] && grep -q '"build"' package.json; then
    /usr/local/bin/npm run build
fi

# Restart the Node.js app using the Plesk Node.js handler
# The handler name is the same as the domain’s Node.js application name
/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain example.com

echo "$(date) – Deploy finished" >> /var/log/plesk-git-deploy.log

3.2 Register the Hook with Plesk

1. In the Plesk Git interface, click the repository name to open its details.
2. Scroll to the Post-receive script field and enter the absolute path to the script, e.g., /var/www/vhosts/example.com/nodeapp/post-receive.
3. Save the configuration.

4. Configuring the Node.js Application in Plesk

1. Go to Websites & Domains > Node.js for the domain.
2. Set the Document root to the folder where app.js (or server.js) resides.
3. Specify the Application startup file (e.g., app.js).
4. Select the desired Node.js version from the dropdown. Plesk installs multiple versions side-by-side, so you can pick the one required by your project.
5. Enable Enable npm install on startup if you want Plesk to run npm install automatically when the app is first created. The post-receive hook will handle subsequent installs.
6. Click Apply. Plesk will start the app using pm2 under the plesk user.

5. Testing the End-to-End Flow

Make a small change in your local repository, commit, and push:

git add .
git commit -m "Test auto-deploy"
git push origin main

After the push, Plesk will:

1. Receive the new commit via the Git extension.
2. Execute the post-receive script, which runs npm install, optional build steps, and restarts the Node.js service.
3. Serve the updated application immediately.

Check the log file you defined (/var/log/plesk-git-deploy.log) for any errors. If the deployment fails, the log will contain the exact command output, making troubleshooting simple.

6. Common Issues and Tips

• Permission problems: Ensure the post-receive script and the repository directory are owned by the plesk user (or the user that runs the webspace). Use chown -R plesk:psa /var/www/vhosts/example.com/nodeapp if needed.
• Missing Node.js binary path: Plesk installs Node.js under /usr/local/bin. Reference the full path in scripts to avoid “command not found” errors.
• Environment variables: If your app relies on .env files, keep them outside the Git-tracked directory (e.g., /var/www/vhosts/example.com/.env) and source them in the hook: source /var/www/vhosts/example.com/.env.
• Large dependencies: For production, use the --production flag with npm install to skip devDependencies, reducing deployment time.
• Windows servers: Plesk on Windows uses PowerShell scripts instead of Bash. The same logic applies – create a post-receive.ps1 script, set execution policy, and reference the script path in the Git extension.

Conclusion

By leveraging Plesk’s Git extension and a simple post-receive hook, you can automate the entire lifecycle of a Node.js application: code push → dependency install → build → restart. This workflow eliminates manual steps, reduces the chance of human error, and keeps your production site in sync with the latest code. The same approach works for any remote Git provider and can be adapted to additional build tools (Gulp, Grunt, etc.) or containerised deployments if your architecture evolves.