Encryption does not solve problems, it shifts problems. You have a plaintext you want to protect. You encrypt with a secret. Now you have a secret you want to protect. What do you do with it? Encrypt? You already did it once. Will it change anything when you do it again?
On the other hand - holding the secret in the binary is probably the wrong approach as it usually means that you also hold your secrets in the source code in the repository. This raises the attack surface on the application and is usually something we want to avoid. Where to hold the secrets then? The next best option is to hold the secrets where are they needed - on the servers the binary is executed on (and only on the servers). This approach also follows the rules of Twelve-Factor App where you want the configuration to be held on the environment.
Make the application run under a technical user. Put all secrets in files protected by filesystem access rights so only the technical user can read them. This is the best you can get in XXI century without additional hardware token support. Magic like manual secret input when the application is started are to impractical for anyone to do.
