Say, a gateway server keeps IPs to a main server and a database in a config file. This makes it easier to change the IPs without having to recompile. Does it really matter if this file gets committed? What conditions would apply to guard an IP address from public knowledge in this scenario?

NOTE: The access to the database is obviously restricted with a password (which is NEVER stored in the source code or repository). Access to the main server is restricted as well. The client is never allowed to connect directly to the main server at first, even if a user had its IP.

  • Changing IPs without having to have the whole world change with you is pretty much why DNS was invented.
    – Blrfl
    Nov 5, 2017 at 5:36
  • @Blrfl Good point, but not really the point of the question. The IP addresses shouldn't change often or at all....but in the unlikely event they do, its preferable to go through a config file, rather than messing with source code. Also for testing purposes the IPs might change VERY often. Nov 5, 2017 at 14:10
  • Putting it in a config file is a step in the right direction but you still have the problem of distributing something new when the IP changes. Embed a canonical FQDN in the program and any change you make to DNS will take effect everywhere once the record's TTL expires. Adding an escape hatch for development or simply making DNS appear differently there is trivial.
    – Blrfl
    Nov 5, 2017 at 15:07
  • Actually that makes a lot of sense. I was planning to rely on restarting the server to pick up the new changes in the config files. I would upvote if I could. Nov 5, 2017 at 15:43

1 Answer 1


IP addresses are typically not sensitive. While knowing which IP addresses correspond to what can have some value to an attacker, if your security relies on certain IP addresses being secret, you've done something horribly wrong. Someone with access to your source code repository likely has a way to find this information some other way, unless it's the case that your source code has been "stolen". If your source code is public, e.g. in a public GitHub repository, it's not clear why you would have this information in the repository of all, since it won't be the right information for anyone outside of your organization. This leads to the next point.

While there isn't much of a security reason not to commit the IP addresses to the repository, it's desirable for them not to be with the source code for other reasons. Typically these kinds of concerns are controlled by an Operations team (Ops). You usually don't want to have replacing a machine or making other network changes require committing changes to the source repository and (presumably) redeploying. This creates the risk of accidentally deploying the wrong version of the code, and may well be a disruptive action even when everything goes as planned. It also requires the Ops team to have knowledge and skills they may not otherwise need, e.g. the branching strategy used by the developers. Nowadays with elastic services and DevOps, even thinking about individual (internal) IP addresses and configuration files is not sustainable. Provisioning tools like Puppet, Chef, Ansible, Terraform, or Salt and configuration services like etcd and Consul automate or eliminate these configuration concerns.

Even if you don't have a separate Operations team, the conceptual divide between developing the software and configuring/provisioning/deploying it is useful to maintain. Also, the above isn't to say that the configuration information shouldn't be stored in some version control system; you very much want to be able to track and audit configuration changes. (I'd go further and say you want to endeavor to make it impossible for configuration changes to happen without going through such a system, e.g. by having reconfiguration happen automatically via some process that watches the repository of configuration information, and "only" that process having the rights to access and make changes to the deployed systems.) However, the above suggests that the configuration information should not be stored in the same repository as the source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.