A deployment server usually needs to fetch a private repository, not modify it. A narrowly scoped deploy key or application credential limits what a compromised deployment account could change.
IN THIS ARTICLE
What you need before you begin
Confirm SSH or supported repository integration is available. Identify the repository owner and whether one repository or several must be accessed.
01 Give a deployment server read-only Git repository access
Create a dedicated key or supported repository credential for the deployment identity. Protect the private component on the server and publish only the public key where required.
Add the public key to the repository’s deploy-key settings with read access only unless write access is explicitly required. For broader multi-repository access, consider the provider’s appropriately scoped application mechanism.
Verify the Git host identity through the provider’s published host-key information. Do not disable host verification simply to make unattended cloning succeed.
Configure the deployment command to use this identity and clone into a non-public release directory. Keep the repository metadata and private key outside the web document root.
Test a fetch as the deployment account and record how the credential will be revoked when the server or project is retired.
Confirm the expected result
Confirm the deployment can fetch the intended repository and does not receive unnecessary write or unrelated repository access. Check private-key file access.
Troubleshoot unexpected results
A permission-denied error can mean the wrong key is offered, the public key belongs to another repository or the remote URL uses a different authentication method.
A common question
Should I copy my personal private SSH key to the server?
Use a dedicated deployment identity where possible. Personal keys can carry broader access and make revocation harder when a server is replaced or shared with a team.