Export Preset Secret Storage Configuration for Testing Integrations

Direct answer

No. As of Godot 4.2 and current 4.x stable releases, export preset fields cannot be marked as secret. Any value entered in the export dialog is written in plain text to export_presets.cfg in the project root. There is no built-in vault, encryption, or per-field masking that excludes the value from version control while keeping it available to the exporter at runtime.

Correcting the premise

The question references .godot and .import files. In Godot 4, .godot is the editor cache directory and .import files are per-asset import metadata. Export preset values live in export_presets.cfg. If a secret appears in a .godot or .import file, it is usually a side effect of the editor caching a resource that was loaded from a preset, not the primary storage location.

What works today

Because the editor has no secret channel, move the credential out of the preset file and into the environment. Keep only a dummy placeholder in the version-controlled preset, and read the real value at runtime with OS.get_environment().

1. In export_presets.cfg, set the field to a non-sensitive placeholder such as DUMMY_API_KEY.
2. Store the real key in your CI secret manager (GitHub Actions Secrets, GitLab CI variables, etc.).
3. In your test scene or autoload, read the environment variable:

   var api_key = OS.get_environment("INTEGRATION_API_KEY")
   if api_key.is_empty():
       push_error("Missing INTEGRATION_API_KEY")

4. If the exporter itself must consume the secret (for example, a custom build step), generate a git-ignored export_presets.cfg or an override resource in CI from a template plus secret-store values, then run the headless export command for your Godot version. Do not commit the generated file.

Should the editor mask values at runtime?

Runtime masking would only reduce accidental display in the editor or logs; it would not protect a value already written to disk. Your own GDScript can still log or transmit the secret, so scrub test output and use least-privilege test keys rather than production credentials.

Future secret-management API

There is no finalized consensus or merged API for secret management in export presets in current Godot releases. Treat any future proposal as unconfirmed until verified against the official Godot proposal tracker and release notes for your target version.

Verification

Before relying on this workflow, confirm the behavior on your exact Godot version:

• In a scratch project, put DUMMY_SECRET in an export preset, save, then run grep -R DUMMY_SECRET . and git status --short to confirm the value lands in export_presets.cfg and whether it is tracked.
• Run a headless export with the secret supplied only through the environment and a git-ignored generated preset; verify the version-controlled tree contains no secret and the test reads it via OS.get_environment().
• Inspect the export log for the dummy value to ensure your harness does not echo environment variables or preset contents.

If your exporter must embed the key into the binary at build time rather than read it at runtime, the recommendation changes: you would need a build-time injection step outside the editor, and the risk profile shifts from version-control leakage to binary extraction.