Keep living documentation by using DNS directly. It's your directory! Get a domain for each of your stages: Say foo.cats for integration, foo.pony for staging,

Keep living documentation by using DNS directly. It's your directory! Get a domain for each of your stages: Say foo.cats for integration, foo.pony for staging, and foo.io for prod. Then have a shorthand for every project and deploy consistently to bar.foo.cats, bar.foo.pony, and bar.foo.io. Deploy to a project name, not a server name. These names are also separate from the public name bar.com used to reach the service on bar.foo.io. If you get NXDOMAIN on bar.foo.cats, you'll know there's no integration-server for that project. If you want to move to a different server, you update your DNS records, not your deploy-scripts. If you want to change the public name of a service you can do it without changing anything about how you access it. Others have mentioned .ssh/config which is one piece of the puzzle. I have shorthands named bar-int, bar-stage, bar-live that point to the respective domains. We work towards having all SSH usernames being the same as the project shorthand. At that point the SSH aliases can be generated automatically from a list of projects.