Mkingst tech specs updated

[mkingst]

Proposed changes

Many Customers have asked for more information on what directories need to be reserved on baremetal installations. This has been added.

Also, removed "deprecated" on the manual steps for VM/Bare-metal, as some customers have issues with the script and may need to resort to installing NIM manually nd those steps are still correct.

Checklist

Before merging a pull request, run through this checklist and mark each as complete.

• I have read the contributing guidelines
• I have signed the F5 Contributor License Agreement (CLA)
• I have rebased my branch onto main
• I have ensured my PR is targeting the main branch and pulling from my branch from my own fork
• I have ensured that the commit messages adhere to Conventional Commits
• I have ensured that documentation content adheres to the style guide
• If the change involves potentially sensitive changes¹, I have assessed the possible impact
• If applicable, I have added tests that prove my fix is effective or that my feature works
• I have ensured that existing tests pass after adding my changes
• If applicable, I have updated README.md and CHANGELOG.md

Footnotes

1. Potentially sensitive changes include anything involving code, personally identify information (PII), live URLs or significant amounts of new or revised documentation. Please refer to our style guide for guidance about placeholder content. ↩

[github-actions]

✅ Deploy Preview will be available once build job completes!

Name	Link
😎 Deploy Preview	https://frontdoor-test-docs.nginx.com/previews/docs/535/

---

[mjang]

love it, @mkingst . @travisamartin if you have a different review, I'll happily yield.

[mjang]

It's a little redundant:

Suggested change

	title: Manually install on a virtual machine or bare metal (Manual Method)
	title: Manually install on a virtual machine or bare metal

[mjang]

Suggested change

This document outlines manual steps to install NGINX Instance Manager. There is also a simplified script-based installation guide on the other section that we reccommend for faster deployment. For most users, we recommend using the updated process documented [here]({{< ref "nim/deploy/vm-bare-metal/install.md" >}}). If there are issues when running the script, these manual steps may be better suited to specific environments. {{</call-out>}}

This document outlines manual steps to install NGINX Instance Manager. For most users, we recommend that you use our script-based process documented [here]({{< ref "nim/deploy/vm-bare-metal/install.md" >}}). If there are issues when running the script, these manual steps may be better suited. {{</call-out>}}

[mjang]

Suggested change

	Below are the directory requirements and storage recommendations for fresh, minimal, and moderate usage (<100 instances) of NGINX Instance Manager (NIM).
	We recommend that you allocate at least the following space on the specified directories. These recommendations apply for fresh, minimal, and moderate usage (<100 instances) of NGINX Instance Manager (NIM).

[mjang]

I presume you're referring to volume requirements for each noted directory

Suggested change

	Important Note: These recommendations apply if you are using NGINX Agent to connect NGINX instances to NIM for full management capabilities (e.g., managing configurations, viewing metrics, applying WAF policies, managing certificates, etc.). If the use case is solely usage reporting, as introduced in R33+, the Agent is not required, and resources needed are significantly reduced. For usage reporting-only deployments, NIM simply receives and stores usage data sent directly from the instances, which does not require the same resource allocation outlined below.
	{{< note >}} These recommendations apply if you are using NGINX Agent to connect NGINX instances to NIM for full management capabilities, such as managing configurations, viewing metrics, applying WAF policies, and managing certificates.
	If the use case is solely usage reporting, as introduced in R33+, you do not need to use NGINX Agent. This significantly reduces required resources. If your deployment is for reporting-only deployments, NIM receives and stores usage data sent directly from the instances, which do not require the same resources outlined here. {{< /note >}}

[mjang]

Some of what's drafted is redundant. However, this is begging for a link to answer "What if I'm deploying > 100 instances of NIM"

Suggested change

	- /var/lib/clickhouse: Stores ClickHouse metrics data; recommend 2.5GB per instance (25GB for 10 instances, 250GB for 100 instances). This is only required if ClickHouse metrics are enabled. In NIM 2.20, lightweight mode can be deployed without ClickHouse (no metrics collected).
	- /var/lib/clickhouse: Stores ClickHouse metrics data; recommend 2.5GB per instance. Required only if ClickHouse metrics are enabled. In NIM 2.20, you can deploy lightweight mode without ClickHouse.

[mjang]

Suggested change

	**Key Considerations**:
	**Key Considerations**:

[mjang]

style. We discourage the use of Latin terms

Suggested change

	-Resources listed above are necessary for instance management using NIM (via NGINX Agent).
	-For usage reporting-only deployments (without management via Agent):
	-Resources listed above are necessary for instance management using NIM (through NGINX Agent).
	-For usage reporting-only deployments (without management through Agent):

[mjang]

Suggested change

	Resource requirements are significantly reduced, as the usage data is only received and stored by NIM. This generally requires much less disk space and memory allocation. The intended use case (management vs. usage reporting) is critical to avoid allocating unnecessary resources. Regular monitoring, backups, and adjustments are still recommended to optimize operations.
	Resource requirements are significantly reduced, as the usage data is only received and stored by NIM. This generally requires much less disk space and memory allocation. The intended use case (management versus usage reporting) is critical to avoid allocating unnecessary resources. We still recommend regular monitoring, backups, and adjustments to optimize operations.