add linter command for checking broken links (#415)

HarshCasper · web-flow · commit ad4c254642d5 · 2026-02-03T07:23:06.000-08:00
diff --git a/README.md b/README.md
@@ -50,6 +50,7 @@ All commands are run from the root of the project, from a terminal:
 | `npm run dev`             | Starts local dev server at `localhost:4321`      |
 | `npm run build`           | Build your production site to `./dist/`          |
 | `npm run preview`         | Preview your build locally, before deploying     |
+| `npm run lint:links`      | Validate internal links in documentation         |
 | `npm run astro ...`       | Run CLI commands like `astro add`, `astro check` |
 | `npm run astro -- --help` | Get help using the Astro CLI                     |
 
diff --git a/astro.config.mjs b/astro.config.mjs
@@ -194,8 +194,9 @@ export default defineConfig({
           leftSidebarEnabled: false,
         }),
         starlightLinksValidator({
-          errorOnRelativeLinks: false,
-          errorOnLocalLinks: false,
+          errorOnRelativeLinks: true,
+          errorOnLocalLinks: false,  // Allow localhost links in tutorials (they're instructional)
+          errorOnInvalidHashes: true,
         }),
         starlightUtils({
           multiSidebar: {
diff --git a/package.json b/package.json
@@ -7,7 +7,8 @@
     "start": "astro dev",
     "build": "astro build",
     "preview": "astro preview",
-    "astro": "astro"
+    "astro": "astro",
+    "lint:links": "astro build"
   },
   "dependencies": {
     "@astrojs/markdoc": "^0.15.10",
diff --git a/src/content/docs/aws/capabilities/security-testing/iam-policy-enforcement.md b/src/content/docs/aws/capabilities/security-testing/iam-policy-enforcement.md
@@ -124,4 +124,4 @@ If the IAM policies are not correctly enforced, you will get an unsuccessful res
 
 ## Feature coverage
 
-The feature coverage is documented in the [IAM coverage documentation]().
+The feature coverage is documented in the [IAM coverage documentation](/aws/capabilities/security-testing/iam-coverage/).
diff --git a/src/content/docs/aws/services/cloudformation.mdx b/src/content/docs/aws/services/cloudformation.mdx
@@ -140,7 +140,7 @@ The Resource Browser allows you to perform the following actions:
 The following code snippets and sample applications provide practical examples of how to use CloudFormation in LocalStack for various use cases:
 
 - [Serverless Container-based APIs with Amazon ECS & API Gateway](https://github.com/localstack/serverless-api-ecs-apigateway-sample)
-- [Deploying containers on ECS clusters using ECR and Fargate]()
+- [Deploying containers on ECS clusters using ECR and Fargate](/aws/tutorials/ecs-ecr-container-app/)
 - [Messaging Processing application with SQS, DynamoDB, and Fargate](https://github.com/localstack/sqs-fargate-ddb-cdk-go)
 
 ## Feature coverage
diff --git a/src/content/docs/aws/services/dynamodbstreams.mdx b/src/content/docs/aws/services/dynamodbstreams.mdx
@@ -13,7 +13,7 @@ The stream records are written to a DynamoDB stream, which is an ordered flow of
 DynamoDB Streams records data in near-real time, enabling you to develop workflows that process these streams and respond based on their contents.
 
 LocalStack supports DynamoDB Streams, allowing you to create and manage streams in a local environment.
-The supported APIs are available on our [DynamoDB Streams coverage page](), which provides information on the extent of DynamoDB Streams integration with LocalStack.
+The supported APIs are available on our [API coverage section](#api-coverage), which provides information on the extent of DynamoDB Streams integration with LocalStack.
 
 ## Getting started
 
diff --git a/src/content/docs/aws/services/elasticache.mdx b/src/content/docs/aws/services/elasticache.mdx
@@ -49,7 +49,7 @@ awslocal elasticache describe-cache-clusters --show-cache-node-info --query "Cac
 }
 ```
 
-The cache cluster uses a random port of the [external service port range]().
+The cache cluster uses a random port of the [external service port range](/aws/capabilities/networking/external-port-range/).
 Use this port number to connect to the Redis instance like so:
 
 ```bash
diff --git a/src/content/docs/aws/services/elb.mdx b/src/content/docs/aws/services/elb.mdx
@@ -174,7 +174,7 @@ http(s)://localhost.localstack.cloud:4566/_aws/elb/example-lb/test/path
 
 The following code snippets and sample applications provide practical examples of how to use ELB in LocalStack for various use cases:
 
-- [Setting up Elastic Load Balancing (ELB) Application Load Balancers using LocalStack, deployed via the Serverless framework]()
+- [Setting up Elastic Load Balancing (ELB) Application Load Balancers using LocalStack, deployed via the Serverless framework](/aws/tutorials/elb-load-balancing/)
 
 ## Current Limitations
 
diff --git a/src/content/docs/aws/services/es.mdx b/src/content/docs/aws/services/es.mdx
@@ -9,7 +9,7 @@ import FeatureCoverage from "../../../../components/feature-coverage/FeatureCove
 ## Introduction
 
 The Elasticsearch Service in LocalStack lets you create one or more single-node Elasticsearch/OpenSearch cluster that behaves like the [Amazon Elasticsearch Service](https://aws.amazon.com/opensearch-service/the-elk-stack/what-is-elasticsearch/).
-This service is, like its AWS counterpart, heavily linked with the [OpenSearch Service](../opensearch).
+This service is, like its AWS counterpart, heavily linked with the [OpenSearch Service](/aws/services/opensearch/).
 Any cluster created with the Elasticsearch Service will show up in the OpenSearch Service and vice versa.
 
 ## Creating an Elasticsearch cluster
@@ -149,7 +149,7 @@ There are three configurable strategies that govern how domain endpoints are cre
 | - | - | - |
 | `domain` | `<domain-name>.<region>.es.localhost.localstack.cloud:4566` | This is the default strategy that uses the `localhost.localstack.cloud` domain to route to your localhost |
 | `path` | `localhost:4566/es/<region>/<domain-name>` | An alternative that can be useful if you cannot resolve LocalStack's localhost domain |
-| `port` | `localhost:<port-from-range>` | Exposes the cluster(s) directly with ports from the [external service port range]()|
+| `port` | `localhost:<port-from-range>` | Exposes the cluster(s) directly with ports from the [external service port range](/aws/capabilities/networking/external-port-range/)|
 | `off` | | *Deprecated*. This value now reverts to the `port` setting, using a port from the given range instead of `4571` |
 
 Regardless of the service from which the clusters were created, the domain of the cluster always corresponds to the engine type (OpenSearch or Elasticsearch) of the cluster.
@@ -204,7 +204,7 @@ localstack@machine % tree -L 4 volume/state
 
 Since LocalStack 1.4.0, the OpenSearch and ElasticSearch services support "Advanced Security Options".
 This feature is currently only supported for OpenSearch domains (which can also be created by the elasticsearch service).
-More info can be found on [the OpenSearch Service docs page](../opensearch#advanced-security-options).
+More info can be found on [the OpenSearch Service docs page](/aws/services/opensearch/#advanced-security-options).
 
 ## Custom Elasticsearch backends
 
diff --git a/src/content/docs/aws/services/glue.mdx b/src/content/docs/aws/services/glue.mdx
@@ -297,7 +297,7 @@ Once the crawler has finished running and is back in `READY` state, the Glue tab
 
 The Glue Schema Registry allows you to centrally discover, control, and evolve data stream schemas.
 With the Schema Registry, you can manage and enforce schemas and schema compatibilities in your streaming applications.
-It integrates nicely with [Managed Streaming for Kafka (MSK)](../managed-streaming-for-kafka).
+It integrates nicely with [Managed Streaming for Kafka (MSK)](/aws/services/kafka/).
 
 :::note
 Currently, LocalStack supports the AVRO dataformat for the Glue Schema Registry.
diff --git a/src/content/docs/aws/services/iam.mdx b/src/content/docs/aws/services/iam.mdx
@@ -15,7 +15,7 @@ By centralizing access control, administrators can enforce the principle of leas
 
 LocalStack allows you to use the IAM APIs in your local environment to create and manage users, groups, and roles, granting permissions that adhere to the principle of least privilege.
 The supported APIs are available on our [API Coverage section](#api-coverage), which provides information on the extent of IAM's integration with LocalStack.
-The policy coverage is documented in the [IAM coverage documentation]().
+The policy coverage is documented in the [IAM coverage documentation](/aws/capabilities/security-testing/iam-coverage/).
 
 ## Getting started
 
diff --git a/src/content/docs/aws/services/kinesisanalyticsv2.mdx b/src/content/docs/aws/services/kinesisanalyticsv2.mdx
@@ -16,7 +16,7 @@ This service was formerly known as 'Kinesis Data Analytics for Apache Flink'.
 [Apache Flink](https://flink.apache.org/) is a framework for building applications that process and analyze streaming data.
 [Managed Service for Apache Flink (MSF)](https://docs.aws.amazon.com/managed-flink/latest/java/what-is.html) is an AWS service that provides the underlying infrastructure and a hosted Apache Flink cluster that can run Apache Flink applications.
 
-LocalStack lets you to run Flink applications locally and implements several [AWS-compatible API operations]().
+LocalStack lets you to run Flink applications locally and implements several [AWS-compatible API operations](#api-coverage).
 
 A separate Apache Flink cluster is started in [application mode](https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/deployment/overview/#application-mode) for every Managed Flink application created.
 Flink cluster deployment on LocalStack consists of two separate containers for [JobManager](https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/concepts/flink-architecture/#jobmanager) and [TaskManager](https://nightlies.apache.org/flink/flink-docs-release-1.20/docs/concepts/flink-architecture/#taskmanagers).
diff --git a/src/content/docs/aws/services/lambda.mdx b/src/content/docs/aws/services/lambda.mdx
@@ -16,7 +16,7 @@ AWS Lambda automatically scales your code to meet demand and handles server prov
 AWS Lambda allows you to break down your application into smaller, independent functions that integrate seamlessly with AWS services.
 
 LocalStack allows you to use the Lambda APIs to create, deploy, and test your Lambda functions.
-The supported APIs are available on our [Lambda coverage page](), which provides information on the extent of Lambda's integration with LocalStack.
+The supported APIs are available on our [API coverage section](#api-coverage), which provides information on the extent of Lambda's integration with LocalStack.
 
 ## Getting started
 
@@ -177,7 +177,7 @@ The following event sources are supported in LocalStack:
 
 The table below shows feature coverage for all supported event sources for the latest version of LocalStack.
 
-Unlike [API operation coverage](), this table illustrates the **functional and behavioural coverage** of LocalStack's Lambda Event Source Mapping implementation.
+Unlike [API operation coverage](#api-coverage), this table illustrates the **functional and behavioural coverage** of LocalStack's Lambda Event Source Mapping implementation.
 
 Where necessary, footnotes are used to provide additional context.
 
@@ -603,7 +603,7 @@ With the new implementation, the following changes have been introduced:
   The configuration `LAMBDA_SYNCHRONOUS_CREATE=1` can force synchronous function creation, but it is not recommended.
 - LocalStack's Lambda implementation, allows you to customize the Lambda execution environment using the [Lambda Extensions API](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
   This API allows for advanced monitoring, observability, or developer tooling, providing greater control and flexibility over your Lambda functions.
-  Lambda functions can also be run on hosts with [multi-architecture support](), allowing you to leverage LocalStack's Lambda API to develop and test Lambda functions with high parity.
+  Lambda functions can also be run on hosts with [multi-architecture support](/aws/capabilities/config/arm64-support/), allowing you to leverage LocalStack's Lambda API to develop and test Lambda functions with high parity.
 
 The following configuration options from the old provider are discontinued in the new provider:
 
diff --git a/src/content/docs/aws/services/opensearch.mdx b/src/content/docs/aws/services/opensearch.mdx
@@ -31,7 +31,7 @@ The following versions of OpenSearch Service are supported by LocalStack:
 - 2.19
 - 3.1 (**default**)
 
-OpenSearch is closely coupled with the [Elasticsearch Service](../elasticsearch).
+OpenSearch is closely coupled with the [Elasticsearch Service](/aws/services/es/).
 Clusters generated through the OpenSearch Service will be visible within the Elasticsearch Service interface, and vice versa.
 You can select an Elasticsearch version with the `--engine-version` parameter while creating an OpenSearch Service domain.
 
@@ -112,7 +112,7 @@ The strategy can be configured via the `OPENSEARCH_ENDPOINT_STRATEGY` environmen
 | ------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
 | `domain` | `<domain-name>.<region>.<engine-type>.localhost.localstack.cloud:4566`             | The default strategy employing the `localhost.localstack.cloud` domain for routing to localhost.     |
 | `path`   | `localhost:4566/<engine-type>/<region>/<domain-name>`                              | An alternative strategy useful if resolving LocalStack's localhost domain poses difficulties.       |
-| `port`   | `localhost:<port-from-range>`                                                      | Directly exposes cluster(s) via ports from [the external service port range](). |
+| `port`   | `localhost:<port-from-range>`                                                      | Directly exposes cluster(s) via ports from [the external service port range](/aws/capabilities/networking/external-port-range/). |
 
 Irrespective of the originating service for the clusters, the domain of each cluster consistently aligns with its engine type, be it OpenSearch or Elasticsearch.
 Consequently, OpenSearch clusters incorporate `opensearch` within their domains (e.g., `my-domain.us-east-1.opensearch.localhost.localstack.cloud:4566`), while Elasticsearch clusters feature `es` in their domains (e.g., `my-domain.us-east-1.es.localhost.localstack.cloud:4566`).
@@ -239,7 +239,7 @@ When using OpenSearch Dashboards with LocalStack, you need to make sure to:
 - Enable the [advanced security options](#advanced-security-options) and set a username and a password.
   This is required by OpenSearch Dashboards.
 - Ensure that the OpenSearch Dashboards Docker container uses the LocalStack DNS.
-  You can find more information on how to connect your Docker container to Localstack in our [Network Troubleshooting guide]().
+  You can find more information on how to connect your Docker container to Localstack in our [Network Troubleshooting guide](/aws/capabilities/networking/).
 
 First, you need to make sure to start LocalStack in a specific Docker network:
 
diff --git a/src/content/docs/aws/services/route53.mdx b/src/content/docs/aws/services/route53.mdx
@@ -96,7 +96,7 @@ test.example.com.       300     IN      A       1.2.3.4
 
 The DNS name `localhost.localstack.cloud`, along with its subdomains like `mybucket.s3.localhost.localstack.cloud`, serves an internal routing purpose within LocalStack.
 It facilitates communication between a LocalStack compute environment (such as a Lambda function) and the LocalStack APIs, as well as your containerised applications with the LocalStack APIs.
-For example configurations, see the [Network Troubleshooting guide]().
+For example configurations, see the [Network Troubleshooting guide](/aws/capabilities/networking/).
 
 For most use-cases, the default configuration of the internal LocalStack DNS name requires no modification.
 It functions seamlessly in typical scenarios.
diff --git a/src/content/docs/aws/services/s3.mdx b/src/content/docs/aws/services/s3.mdx
@@ -148,7 +148,7 @@ Check out our [SDK documentation](/aws/tooling/localstack-sdks/) to learn how yo
 :::tip
 While using [AWS SDKs](https://aws.amazon.com/developer/tools/#SDKs), you would need to configure the `ForcePathStyle` parameter to `true` in the S3 client configuration to use **Path style** requests.
 If you want to use virtual host addressing of buckets, you can remove `ForcePathStyle` from the configuration.
-The `ForcePathStyle` parameter name can vary between SDK and languages, please check our [SDK documentation]()
+The `ForcePathStyle` parameter name can vary between SDK and languages, please check our [SDK documentation](/aws/integrations/aws-sdks/)
 :::
 
 If your endpoint is not prefixed with `s3.`, all requests are treated as **Path style** requests.
diff --git a/src/content/docs/aws/services/sqs.mdx b/src/content/docs/aws/services/sqs.mdx
@@ -373,7 +373,7 @@ Our Lambda implementation automatically resolves these URLs to the LocalStack co
 When your code run within different containers like ECS tasks or your custom ones, it's advisable to establish your Docker network setup.
 You can follow these steps:
 
-1. Override the `LOCALSTACK_HOST` variable as outlined in our [network troubleshooting guide]().
+1. Override the `LOCALSTACK_HOST` variable as outlined in our [network troubleshooting guide](/aws/capabilities/networking/).
 2. Ensure that your containers can resolve `LOCALSTACK_HOST` to the LocalStack container within the Docker network.
 3. We recommend employing `SQS_ENDPOINT_STRATEGY=path`, which generates queue URLs in the format `http://<LOCALSTACK_HOST>/queue/...`.
 
diff --git a/src/content/docs/aws/tooling/vscode-extension.md b/src/content/docs/aws/tooling/vscode-extension.md
@@ -72,7 +72,7 @@ The AWS Toolkit for VS Code, a separate VS Code extension available from Amazon,
 
 ## Contributing
 
-[Read our contributing guidelines](./CONTRIBUTING.md) to learn how you can help.
+[Read our contributing guidelines](https://github.com/localstack/localstack-toolkit-vscode/blob/main/CONTRIBUTING.md) to learn how you can help.
 
 
 ### LocalStack Toolkit for VS Code extension support
diff --git a/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx b/src/content/docs/aws/tutorials/schema-evolution-glue-msk.mdx
@@ -19,7 +19,7 @@ It is used to capture data generated by producers and distribute it among its co
 Kafka is known for its scalability, with reports of production environments scaling to [trillions of messages per day](https://engineering.linkedin.com/blog/2019/apache-kafka-trillion-messages).
 With [Amazon Managed Streaming for Apache Kafka (MSK)](https://aws.amazon.com/msk/), AWS provides a service to provision Apache Kafka clusters easily.
 
-[LocalStack Pro](https://app.localstack.cloud/) supports [Amazon Managed Streaming for Kafka (MSK)](aws/services/msk), which enables you to spin up Kafka clusters on your local machine and test the integration of your applications with Amazon MSK.
+[LocalStack Pro](https://app.localstack.cloud/) supports [Amazon Managed Streaming for Kafka (MSK)](/aws/services/kafka/), which enables you to spin up Kafka clusters on your local machine and test the integration of your applications with Amazon MSK.
 
 Kafka clusters are often used as the central messaging infrastructure in complex microservice environments.
 However, the continuous and independent development of the individual microservices - the data producers and consumers - can make it hard to coordinate and evolve data schemas over time without introducing application failures due to incompatibilities.

Original file line number	Diff line number	Diff line change
`@@ -124,4 +124,4 @@ If the IAM policies are not correctly enforced, you will get an unsuccessful res`
`124`	`124`
`125`	`125`	`## Feature coverage`
`126`	`126`
`127`		`-The feature coverage is documented in the [IAM coverage documentation]().`
	`127`	`+The feature coverage is documented in the [IAM coverage documentation](/aws/capabilities/security-testing/iam-coverage/).`
Original file line number	Diff line number	Diff line change
`@@ -49,7 +49,7 @@ awslocal elasticache describe-cache-clusters --show-cache-node-info --query "Cac`
`49`	`49`	`}`
`50`	`50`	```
`51`	`51`
`52`		`-The cache cluster uses a random port of the [external service port range]().`
	`52`	`+The cache cluster uses a random port of the [external service port range](/aws/capabilities/networking/external-port-range/).`
`53`	`53`	`Use this port number to connect to the Redis instance like so:`
`54`	`54`
`55`	`55`	```bash