Add support for reading environment variables from `.env` files

[ANGELUSD11]

Describe the project you are working on

My game is a simple 2d space shooter, but to implement a communication bridge with external services, I rely on a parser to avoid exposing my tokens and sensitive data. For example, I have several implementations with the Discord API to use bots or user state.

Describe the problem or limitation you are having in your project

Not having native support for .env environment variable files .env

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I understand that exposing keys or tokens directly inside a project can be a security risk, but having native support for loading environment variables from a .env file would provide a clean and standardized way to configure external services or APIs. This would avoid the need for custom parsers, reduce duplicated solutions across projects, and offer a more reliable workflow for developers who integrate external backends or cloud services.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Add a built-in API to load .env files at runtime or at project startup.
Provide a simple method in GDScript/C#/C++ such as:

var config = Env.load(".env")
var api_key = config.get("API_KEY")

This would allow developers to retrieve environment variables in a consistent and engine-supported way without needing custom parsers or third-party add-ons.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Even if the code is short, it still needs to be maintained, tested across platforms, and kept compatible with future engine releases. Having an official implementation avoids the long-term maintenance burden for users.

Is there a reason why this should be core and not an add-on in the asset library?

Right now, every developer who needs .env support must either write their own parser, copy code from other projects, or install third-party add-ons of varying quality. Native support ensures consistency, reliability, and long-term maintenance.

[sockeye-d]

You can use ConfigFile or JSON or XML for this. Use FileAccess.get_as_string("res://env.ini") and parse it with whatever method you see fit.

However, this plaintext file will be exported as plaintext in the final project, making it trivial to reverse engineer your keys with something like gdsdecomp, so be very careful with how you use it.

[ANGELUSD11]

Thank you for the clarification.
I’m aware that ConfigFile, JSON, and XML can be used to store configuration values, but .env files serve a different purpose: they are meant to represent environment variables, not internal project configuration.

I fully agree that .env files should not be exported as plaintext with sensitive keys. My proposal is not to store secrets inside exported projects, but to provide a built-in, consistent way to load environment-based configuration during development or when running server-side tools, without every user needing to re-implement a parser.

[sockeye-d]

It's not hard to write a custom handler if you really want to stick to the KEY=VALUE syntax:

func import_env_vars(path: String) -> void:
	var file := FileAccess.get_file_as_string(path)
	for line in file.split("\n"):
		var data := line.split("=")
		OS.set_environment(data[0], data[1])

Note

OS.set_environment sets the environment variable for this process, so it will be transferred to child processes but not any others.

If you want to get the values back out, use OS.get_environment("KEY")

[timothyqiu]

I think it would be sufficient if custom environment variables can be configured in the Run Instances dialog.

[Calinou]

I think it would be sufficient if custom environment variables can be configured in the Run Instances dialog.

That makes sense, although the setting that sets environment variables for all instances shouldn't be persisted to project.godot (unlike Main Run Args). Otherwise, this breaks the point of ensuring environment variables are kept out of version control.