What causes "TPM functionality is not supported on this platform" in nats-io/nats-server?

Use a nats-server build compiled with TPM support for your platform (the platform-specific implementation file)

TPM functionality is not supported on this platform

Error message

TPM functionality is not supported on this platform

What it means

This is the build-tag stub of the TPM package used on platforms without TPM support (js_ek_tpm_other.go). LoadJetStreamEncryptionKeyFromTPM unconditionally returns this error, so requesting JetStream encryption key loading from a TPM on an unsupported OS/build always fails. Only builds with TPM support (the corresponding platform-specific file) can load keys from a TPM.

Source

Thrown at server/tpm/js_ek_tpm_other.go:22

// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

//go:build !windows

package tpm

import "fmt"

// LoadJetStreamEncryptionKeyFromTPM here is a stub for unsupported platforms.
func LoadJetStreamEncryptionKeyFromTPM(srkPassword, jsKeyFile, jsKeyPassword string, pcr int) (string, error) {
	return "", fmt.Errorf("TPM functionality is not supported on this platform")
}

View on GitHub (pinned to 3a66a489d2)

Solutions

Use a nats-server build compiled with TPM support for your platform (the platform-specific implementation file)
Remove the TPM-based encryption key configuration and supply the JetStream encryption key via a non-TPM mechanism (key file/environment)
If hardware TPM is intended, verify /dev/tpm* or the TPM device is available and the binary variant supports it
Fall back to software-based encryption keys on unsupported platforms

Example fix

// before (server config on unsupported platform)
jetstream {
  key_source: tpm
}
// after
jetstream {
  key_file: "/etc/nats/enc.key"
}

Defensive patterns

Strategy: fallback

Validate before calling

// at startup, guard TPM key loading with a platform check
if !tpmSupported() || tpmDeviceMissing() {
    key, err := loadKeyFromFile("/etc/nats/enc.key")
    if err != nil { return err }
}

Type guard

func tpmAvailable() bool {
    if runtime.GOOS == "windows" { return false } // build without TPM support
    if _, err := os.Stat("/dev/tpmrm0"); err != nil { return false }
    return true
}

Try / catch

key, err := tpm.LoadJetStreamEncryptionKeyFromTPM(srk, file, pass, pcr)
if err != nil && strings.Contains(err.Error(), "not supported on this platform") {
    key, err = loadSoftwareKeyFallback() // file/env based key
}

Prevention

Check platform/TPM support before configuring TPM-based key loading
Deploy TPM-enabled server builds where TPM keys are required
Pass through TPM devices into containers
Always configure a non-TPM key fallback for portability

When it happens

Trigger: Calling initJetStreamEncryption configured to source the JetStream encryption key from a TPM (via TPM-related config such as srk password, key file, key password, and PCR) on a platform compiled without TPM support; i.e., invoking LoadJetStreamEncryptionKeyFromTPM in a non-TPM build.

Common situations: Running nats-server built from source with default tags on Linux without the TPM-enabled variant, deploying a container image without TPM device passthrough/support, or copying a config with TPM key settings between machines with different platforms.

Related errors

AI-assisted analysis of nats-io/nats-server@3a66a489d2 (2026-09-02). Data as JSON: /api/errors/8bd50398b6c90fac. Report an issue: GitHub.