Terraform Naming Convention Validator

The Terraform Naming Convention Validator checks every resource name in a configuration against a standard naming convention so that your modules stay readable, grep-able, and consistent across teams. In large code bases, a shared naming rule is the cheapest governance you can enforce: it removes arguments about style and makes addresses predictable. This validator enforces five rules. Names must be lowercase, which avoids confusing matches between providers that are case-insensitive on some platforms. Names must use hyphens rather than underscores, matching DNS-friendly identifiers. Names must be between one and sixty-four characters so they fit common label limits. Names must not start or end with a hyphen, which would be an invalid identifier. Finally, names should embed an environment token such as dev, test, stg, stage, prod, prd, shared or common so that a reader can tell at a glance which environment a resource belongs to. The tool parses your pasted HCL with the shared tfParse engine, walks every resource block, and reports each violation with its address and a plain explanation. Nothing is uploaded and no cloud connection is made; the whole check runs in your browser. Because the rules are simple and deterministic, the validator is also a good teaching aid for code review and for onboarding engineers who are new to Terraform and to your organisation naming standards. Good names also make state operations, imports, and terraform state mv commands far less error prone because the address you type matches what the plan shows.

• Lowercase rule - flags any uppercase letter in a resource name and suggests the lowercased form.
• Hyphens not underscores - flags underscores and reminds you to use hyphens for DNS-friendly identifiers.
• Length rule - flags names shorter than one or longer than sixty-four characters.
• Edge hyphen rule - flags names that start or end with a hyphen, which are invalid identifiers.
• Environment token - flags names missing an environment token from the approved list.
• Address context - every finding shows the full resource address, not just the name.
• Severity tags - structural issues are MEDIUM, the token hint is LOW.
• HCL parsing - uses the shared parser so real Terraform syntax is understood.
• Pass report - a clear PASSED message when no issues are found.
• Exportable - copy, download as markdown, or print the report.
• Batch friendly - paste many resource blocks at once and get every violation in a single report.
• Zero config - no token list or schema to upload; just paste and validate.
• Deterministic - the same input always yields the same report so CI output is stable.

1. Paste your configuration into the Terraform .tf box on the left. Include the resource blocks whose names you want to check.
2. Click Validate names to parse the HCL and run all five rules locally.
3. Read the report on the right. Each finding lists the resource address, the broken rule, and a short explanation.
4. Sort by severity using the stats row: fix MEDIUM structural issues first, then consider the LOW token hints.
5. Rename the flagged resources in your own editor; this tool does not rewrite your files.
6. Re-run the validator after editing until you see the PASSED message.
7. Share the report via Copy, Copy as Markdown, or Download for a pull request or review.
8. Use the sample button to load a deliberately broken configuration and watch every rule fire at once before trying your own.

Example 1 - passing name. The resource name "app-prod-web" is lowercase, hyphenated, in range, and contains the prod token, so it passes all rules.

Example 2 - case and underscore. "My_Resource" fails the lowercase rule and the no-underscore rule and is reported as MEDIUM.

Example 3 - missing token. "web" passes the structure rules but triggers a LOW hint because it has no environment token.

Example 4 - edge hyphen. "bad-name-" fails the edge-hyphen rule because it ends with a dash.

Example 5 - too long. A sixty-five character name fails the length rule and is reported as MEDIUM so it can be shortened before it reaches a provider limit.

• Consistent modules - enforced naming keeps a large repository easy to read.
• Fewer mistakes - predictable addresses reduce copy-paste errors in plans.
• Fast reviews - a PASSED report is quick evidence for code review.
• Local and private - your configuration never leaves the browser.
• Teaches the standard - explanations help new engineers learn the rules.
• Portable output - export the report anywhere you track decisions.
• Auditable - the exported report is evidence you can attach to a compliance or change ticket.