In this article10 sections
Uploading a site by hand works for the first deploy and fails from the second one onward. Files get missed, an old version stays on the server, and a fix made directly in production never makes it back into the repository. Git deployment solves that: the server pulls the code you committed, and every deploy is the same command. This guide shows how to connect a Git repository to a website in Plesk on Windows hosting, how to deploy and roll back, and how to keep the server’s secrets out of the repository.
SiteHarbour’s Windows hosting plans run Plesk, and Plesk’s Git tools work with a repository you host yourself or on a provider. The steps below use a remote repository that the server can read.
Before you start
- A Git repository that contains the application source, and the production build steps it needs.
- A read-only deploy key or an access token for the repository, created for the server only. Do not use your personal password.
- The website already created in Plesk, as described in how to create a website and install SSL in Plesk.
Step 1: Keep build output and secrets out of the repository
Add a .gitignore file that excludes the folders the build creates, and the files that hold secrets. For a .NET project, that means bin/, obj/, publish/ and appsettings.Production.json. Commit the ignore file before you connect the server, so no secret enters the history.
git check-ignore -v appsettings.Production.jsonExpected: a line that names the ignore rule. If the command prints nothing, the file is not ignored, and it must not be committed.
Step 2: Create a read-only deploy key
On the server, generate a key pair for the deploy. Give the public key to your repository host as a read-only deploy key. Keep the private key in Plesk’s Git settings, not in a file in the website folder. A read-only key cannot push changes, so a compromised server cannot rewrite the repository.
Expected: the repository host lists the key as a read-only deploy key for this one repository, and the server can read it.
Step 3: Connect the repository to the website
In Plesk, open the website and find the Git section. Enter the repository address, choose the branch to deploy, such as main, and select the deploy key. Set the deploy path to the website’s httpdocs folder, or a subfolder of it for an application that lives there.
Expected: the repository status shows the branch and the latest commit that the server has. Run the first deploy from Plesk and check that the files appear in the folder.
Step 4: Add the build steps
A Git deploy copies source files, not a built application. For a .NET app, the server or your build step needs to publish the project into the folder IIS serves. Plesk’s deployment can run a script after the pull. Keep the script short and in the repository, so it is reviewed like the rest of the code:
dotnet publish -c Release -o ./publishPoint IIS at the publish folder, or copy its contents into httpdocs as the final step. Expected: after a deploy, the site runs the new version without any manual upload.
Step 5: Deploy and check the result
Deploy from Plesk, then check three things: the site loads, the new feature you changed is visible, and the application log shows no errors at startup. Check the commit shown in the Git section matches the commit you meant to deploy.
If the site fails after a deploy, roll back to the previous commit. In the Git settings, choose the earlier commit and deploy it. Rolling back is safer than fixing forward on a live site, which is why the backup in how to back up a Plesk website and restore it matters too.
Step 6: Keep secrets on the server
The production connection string and any API keys belong in the website’s environment settings in Plesk, or in a file on the server that is not in the repository. The deploy must never overwrite that file. Exclude it from the copy step, and check after each deploy that it is still present.
Step 7: Automate with care
Some teams deploy on every push to the branch. That is convenient, but a broken commit then goes live immediately. Deploy on push only for a staging site. Use a manual deploy for production, after the staging site passes.
Common mistakes
- A personal password in the server settings. Use a deploy key with read-only access.
- Committing secrets. Ignore the production settings file before the first commit.
- Deploying without a build step. The source files alone do not run as a Windows site.
- Overwriting the production settings file. Keep it outside the copied folder.
- Deploying from a local branch. Deploy a commit that is on the shared branch, so the history matches the server.
Frequently asked questions
Do I need Git on the server?
Plesk handles the pull for you when you connect the repository. You do not need to run Git commands by hand, though it is useful to know them for troubleshooting.
Can I use a repository on a private host?
Yes, as long as the server can reach it and the deploy key has read access. Check that the port and address are allowed from the hosting server.
How do I roll back quickly?
Deploy the previous commit from the Git section. Keep a backup of the site as well, because a rollback does not restore data changed by the new version.
Does this replace the manual upload?
Yes, for the application code. The database and uploaded files need their own backup and restore path.
A Git deploy turns a risky manual upload into one repeatable step. Ignore the build output and the secrets, use a read-only deploy key, deploy a known commit, and keep a rollback path. For the scheduled work that many sites need after a deploy, read how to set up scheduled tasks in Plesk.