Why does os.Open("config.yaml") work in local development but fail when the same Go binary runs as a service?

Two different directories get confused here, and separating them answers the question. ## 1. The current working directory Every process has one, and it is **inherited from the process that started it**. When you run a program from a terminal, the shell's directory becomes the program's directory. When a supervisor, a container runtime, a scheduler or an IDE starts it, that parent decides — often `/`, often a configured value, rarely the directory you had in mind. The operating system resolves every *relative* path — `"config.yaml"`, `"./data"`, `"../shared"` — against it, at the moment of the syscall. `os.Getwd() (string, error)` reports it. Note the error: the directory the process is sitting in can be deleted while the process runs, and then even asking becomes an error. So `os.Open("config.yaml")` is not really asking for a file; it is asking for "config.yaml, relative to wherever we happen to have been started". During development you are almost always standing in the project directory when you run it, and that is why it works. In production nothing puts you there. ## 2. Where the binary lives `os.Executable() (string, error)` returns the path of the executable that started the current process. This is what people reach for when they want "the file that shipped next to my binary": exe, err := os.Executable() if err != nil { return err } cfg := filepath.Join(filepath.Dir(exe), "config.yaml") That is legitimate, but it comes with documented caveats worth stating in an interview: - If the process was started through a **symlink**, the result may be the symlink or the path it points to, depending on the operating system. - There is **no guarantee the path still points at the right executable**. On Unix the file can be renamed, replaced by a deploy, or deleted while the process keeps running. - The result is not a promise about *anything else* being next to it. `go install` puts the binary in a bin directory on its own; a minimal container image copies the binary and nothing more. "Next to the binary" is a deployment convention, not a language guarantee. `os.Args[0]` is not a substitute either: it is whatever the parent chose to pass as the program name, and a parent may pass anything at all. ## 3. What to do about it Ranked roughly by robustness: 1. **Embed the file** into the binary with the `//go:embed` directive when it is genuinely static — templates, migrations, a default configuration. Then there is no path and no failure mode. 2. **Take the path explicitly** from configuration, and make it absolute. The program stops guessing and the operator can see exactly what it will read. 3. **Set the working directory deliberately** in the deployment description if relative paths must keep working, and say so in the program's documentation. 4. **Derive it from `os.Executable`** when the asset really does ship alongside the binary, accepting the caveats above. What you should not do is call `os.Chdir` at some later point to "fix" it: that changes the directory for the whole process, including every other goroutine. ## The interview signal The crisp version of the answer is one sentence: *relative paths resolve against the directory the process was started in, not against the source tree and not against the binary's location.* Everything else — `os.Getwd`, `os.Executable`, embedding — is how you make the program stop caring.