GoLand local run configuration and remote Go SDK environment parity

Goal

Keep a GoLand run configuration that builds successfully with the local Go SDK consistent when the same configuration runs against a remote Go interpreter used for production deployment.

Constraints and uncertainty

GoLand stores environment variables, working directory, and Go SDK selection per run configuration. Local values frequently differ from remote SSH or Docker interpreters. Go module proxy, GOPRIVATE, CGO_ENABLED, and build-tag behavior is evaluated by the active SDK and is not copied automatically. Remote interpreter path mappings require manual alignment between local and remote filesystems. Because settings are user-scoped and may not be version controlled, GoLand does not validate a local configuration against a deployment profile.

Which settings must match between a local GoLand run configuration and a remote production Go SDK for build behavior to remain consistent? Is manual duplication of environment variables and path mappings the supported approach, or should configuration be managed externally? What happens to CGO_ENABLED and build tags when the local SDK differs from the remote production SDK?