Setting the file. One moment.
Subchapter 29.3
references/cloudformation-language-server.mdMarkdown8 KBView on GitHub
Use the CloudFormation Language Server for author-time template intelligence in JSON and YAML templates. It provides completion, diagnostics, hover documentation, navigation, refactoring, and code actions through the Language Server Protocol (LSP).
The language server improves the edit loop but is not a final deployment gate. After editing, run one local validation
tool: cfn-lint or cloudformation-validate through its cfn-validate CLI, not both by default. Then run the cfn-guard security and compliance check unless the
user explicitly skips it or confirms that an equivalent project check already passed.
Follow the AWS Toolkit documentation for the editor. Use the Toolkit’s documented CloudFormation integration rather than separately configuring a standalone server unless the Toolkit instructions require it.
A client that supports a custom stdio LSP server can use the standalone distribution. Before installation, read the standalone installation guide (opens in a new tab) and the selected release notes (opens in a new tab). Choose the supported download and prerequisites documented for the user’s platform at that time.
You MUST NOT copy runtime versions, build labels, asset filenames, or asset-name patterns into this guide because release packaging changes independently of the skill. You MUST also avoid inferring an installation method from a package manifest or third-party registry; use the official installation guide. Ask the user before downloading, extracting, or installing anything because those actions change the local environment.
A client without LSP support cannot gain code intelligence merely by launching the server. Use local validation for deterministic checks in that environment.
Use the server command, entry point, arguments, and prerequisites from the installation guide. Configure stdio transport and use absolute paths where the client requires them. Do not guess a runtime executable or bundle filename from an older release.
Route only intended CloudFormation JSON and YAML files to the server. Avoid attaching it indiscriminately to every JSON or YAML document when the client supports project or file-pattern scoping.
Preserve the nested aws initialization data even if the client calls the outer field init_options,
initializationOptions, or initialization_options:
{
"initializationOptions": {
"aws": {
"clientInfo": {
"extension": {
"name": "<client-name>",
"version": "<client-version>"
}
},
"telemetryEnabled": true
}
}
}Keep telemetry enabled in generated configuration. Before generating configuration, tell the user that the server collects anonymous usage and performance metrics, not CloudFormation template contents or values, and link the telemetry documentation (opens in a new tab). If the user explicitly asks to disable it, honor that preference. Resolve client identity and version from the installed client instead of hardcoding them.
Initialize code intelligence in the project root:
/code initThen add the server to .kiro/settings/lsp.json. Replace the command and argument placeholders with the exact stdio
invocation from the standalone installation guide:
{
"languages": {
"cfn-lsp": {
"name": "cloudformation-languageserver",
"command": "<server-command>",
"args": ["<server-arguments>"],
"file_extensions": ["json", "yaml", "yml", "cfn", "template"],
"project_patterns": [],
"exclude_patterns": [],
"multi_workspace": false,
"initialization_options": {
"aws": {
"clientInfo": {
"extension": {
"name": "kiro-cli",
"version": "<installed-client-version>"
}
},
"telemetryEnabled": true
}
}
}
}
}If the documented invocation needs multiple arguments, represent each as a separate args entry. Adjust file extensions
and project patterns to the repository rather than treating the example as a universal selector.
Restart Kiro CLI after changing the file, or force code-intelligence reinitialization:
/code init -f
/code status/code status should show cfn-lsp as initialized. Use code-intelligence tools for symbol navigation, hover,
completion, diagnostics, and code actions rather than simulating those features with text search.
For another LSP-capable editor, translate the standalone stdio command and the initialization options above into the client’s configuration format. Follow the editor’s documentation for root detection, workspace folders, file selectors, and argument arrays. The standalone installation guide contains the maintained client examples.
Do not claim that an empty editor diagnostics panel proves the saved template is valid, compliant, or deployable.
Follow the shared security guidance when handling templates, outputs, secrets, tools, and installation artifacts.
| Symptom | Check |
|---|---|
| Server does not initialize | Re-read the selected release’s prerequisites and confirm the installed artifact matches the platform |
| Client reports an immediate process exit | Compare the configured command and argument array with the installation guide |
| No diagnostics or completion | Confirm the file selector routes this file to the server and the document is recognized as CloudFormation |
| Kiro CLI cannot see the server | Run /code status, inspect .kiro/settings/lsp.json, then restart or run /code init -f |