feat: create node with identity from provided key

[MicBun]

resolves: https://github.com/trufnetwork/truf-network/issues/1244

Summary by CodeRabbit

• New Features

  • Support supplying a private key via TN_PRIVATE_KEY to set node identity deterministically.
  • Added .env file support in Docker Compose for easier environment configuration.
  • Clearer startup logs indicating whether configuration is generated, provided, or loaded from persistent storage.

• Chores

  • Updated container startup flow to handle private key validation and secure storage.
  • Standardized messaging around configuration initialization and reuse during node startup.

[coderabbitai]

Walkthrough

Updates tn-node startup in deployments/infra/stacks/docker-compose.template.yml: adds .env support, revises initialization logs, and introduces conditional override of generated node identity using TN_PRIVATE_KEY with validation and nodekey.json creation, while preserving existing-config detection and subsequent node start sequence.

Changes

Cohort / File(s)	Summary of Changes
Docker compose startup and key handling deployments/infra/stacks/docker-compose.template.yml	- Add env_file: .env to tn-node service - Adjust log messages for configuration detection and generation - Add TN_PRIVATE_KEY override path with 64-hex validation, write nodekey.json (type: secp256k1), set permissions - Preserve existing-config branch with updated messaging

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant U as User/.env
  participant DC as docker-compose
  participant C as tn-node Container
  participant FS as Persistent Storage
  participant KW as kwild

  DC->>C: Start service (env_file: .env)
  C->>FS: Check existing node configuration
  alt Config exists
    C->>C: Log "Using existing node configuration from persistent storage."
  else No config
    C->>C: Log "No existing configuration found. Generating new node configuration..."
    alt TN_PRIVATE_KEY provided
      U-->>C: TN_PRIVATE_KEY
      C->>C: Validate 64-hex
      C->>FS: Write /root/.kwild/nodekey.json (type: secp256k1)
      C->>FS: Set permissions
      C->>C: Log "Node identity set from provided private key."
    else No TN_PRIVATE_KEY
      C->>C: Generate node identity
      C->>C: Log "Using generated node identity."
    end
  end
  C->>KW: Start node

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat: setup node inside AWS AMI Instance #1172 — Similar edits to docker-compose template adding .env and TN_PRIVATE_KEY handling for nodekey.json generation.
• chore: enhance AMI with streamlined node configuration and setup #1182 — Adjusts private-key handling and startup messaging in the same template and flow.

Suggested reviewers

• outerlook

Poem

I twitch my whiskers at keys in the night,
A hex of sixty-four—just right, just right.
From .env burrows, configs arise,
Node wakes up with keen, bright eyes.
Hop, write, chmod—then off I go,
Ears to the wind, I start the node. 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title succinctly and accurately describes the primary new feature of the pull request, namely creating a node identity from a provided key, and it follows conventional commit formatting without extraneous detail.
Linked Issues Check	✅ Passed	The changes implement the core objective of issue #1244 by validating a provided TN_PRIVATE_KEY, writing it to nodekey.json, and using it as the node identity when present, thereby fulfilling the requirement to allow existing private keys to be used for node creation.
Out of Scope Changes Check	✅ Passed	All modifications, including adding the env_file directive and updating startup messages, are related to supporting the new private key override behavior and do not introduce changes unrelated to the linked issue’s objectives.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch amiWithPrivate

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🧪 Early access (Sonnet 4.5): enabled

We are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience.

Note:

• Public repositories are always opted into early access features.
• You can enable or disable early access features from the CodeRabbit UI or by updating the CodeRabbit configuration file.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[holdex]

Time Submission Status

Member	Status	Time	Action	Last Update
MicBun	✅ Submitted	4h 30min	Update time	Sep 30, 2025, 12:10 PM
@outerlook	❌ Missing	-	⚠️ Submit time	-

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5a33433 and f10f5a4.

📒 Files selected for processing (1)

• deployments/infra/stacks/docker-compose.template.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: acceptance-test

🔇 Additional comments (5)

deployments/infra/stacks/docker-compose.template.yml (5)

25-26: LGTM!

Adding .env file support is a standard approach for injecting environment variables like TN_PRIVATE_KEY into the container.

---

45-45: LGTM!

The updated log message more accurately reflects that the entire node configuration is being generated, not just the identity.

---

59-59: LGTM!

The comment accurately describes the initialization step.

---

69-72: Validation is format-only, not cryptographic.

The hex format validation ensures the key is 64 characters, but doesn't verify that it's a valid secp256k1 private key. This is acceptable since kwild will reject invalid keys at startup, providing fail-fast behavior.

---

79-81: LGTM!

The updated message is consistent with the terminology changes elsewhere and accurately describes the else branch behavior.