Reputation: 21
I have created a deploy key from a server instance, say host A for repository R1. Now I am scaling to 3 servers, i.e. to host B and host C and want to access R1 from them.
How to use deploy keys when it comes to multiple server instances? Do I have to copy the deploy key to other servers or do I have to generate new ones on host B and host C and add them to the GitHub repository settings?
Which of them is an ideal way for supporting auto scalability?
Upvotes: 0
Views: 180
Reputation: 76489
If you have a central service whose job it is to deploy code, then the best approach is to use one deploy key for that service and control your deployments using that service. However, it doesn't sound like that's what's going on here.
Absent that, you generally want to use one deploy key for each environment that you're deploying to, not each server. For example, if you have code that needs to be deployed to production application servers as well as developer shell servers, then use a separate deploy key for each environment and copy each environment's key to all of the servers in that environment. That way, you can later restrict access to the repository if a certain environment no longer needs it without impacting other environments.
Using a separate key for each environment means that if you have deployment scripts that need to work with multiple deploy keys (for multiple repositories), they'll function in the same way on every server in that deployment.
You should make sure that your deploy keys are well labeled so that future you (or your successor) can figure out at a glance what each key is for.
Upvotes: 0