The provided init scripts make orchestrator start and run as the root user. That's really not necessary, so it would be good to provide sample init scripts that start orchestrator as a (dedicated?) non-root user.

I would suggest

• detecting if running as root and issuing a warning that it's better not to
• making the init scripts try to start orchestrator as the orchestrator user or some specific non-root user
• add comments that any routines called by orchestrator may need to run via sudo to gain enhanced privileges if moving from the current setup.
• binding to port 80 (or low ports) may be troublesome, perhaps requiring orchestrator to drop privileges (not sure if that's an issue in go or somehow configuring the user to have such privileges. That's likely to depend on the OS being used, but as not everyone will be binding to low ports this may not be such an issue.
• ensure that log writing can write to the appropriate file(s).
• this is really not a new issue and it has been resolved by many other applications and it seems to make sense for orchestrator too.