diff --git a/public/images/aws/deploy-lambda-function.gif b/public/images/aws/deploy-lambda-function.gif
new file mode 100644
index 00000000..5ff8f616
Binary files /dev/null and b/public/images/aws/deploy-lambda-function.gif differ
diff --git a/public/images/aws/invoke-lambda-function.gif b/public/images/aws/invoke-lambda-function.gif
new file mode 100644
index 00000000..3b8e163c
Binary files /dev/null and b/public/images/aws/invoke-lambda-function.gif differ
diff --git a/src/content/docs/aws/capabilities/chaos-engineering/chaos-api.md b/src/content/docs/aws/capabilities/chaos-engineering/chaos-api.md
index d988d03e..636f0edb 100644
--- a/src/content/docs/aws/capabilities/chaos-engineering/chaos-api.md
+++ b/src/content/docs/aws/capabilities/chaos-engineering/chaos-api.md
@@ -183,7 +183,7 @@ The rule to be removed must be exactly the same as in the existing configuration
## Comparison with Fault Injection Service
-AWS [Fault Injection Service (FIS)]({{< ref "fis" >}}) also allows controlled chaos engineering experiments on infrastructure.
+AWS [Fault Injection Service (FIS)](/aws/services/fis) also allows controlled chaos engineering experiments on infrastructure.
While similar in purpose, there are notable differences between FIS and LocalStack Chaos API.
This table highlights those differences, offering a detailed comparison of how each service approaches chaos engineering, their capabilities, and their integration options.
diff --git a/src/content/docs/aws/capabilities/chaos-engineering/chaos-engineering-dashboard.md b/src/content/docs/aws/capabilities/chaos-engineering/chaos-engineering-dashboard.md
index 5ec48178..7af87ae0 100644
--- a/src/content/docs/aws/capabilities/chaos-engineering/chaos-engineering-dashboard.md
+++ b/src/content/docs/aws/capabilities/chaos-engineering/chaos-engineering-dashboard.md
@@ -10,7 +10,7 @@ sidebar:
The Chaos Engineering Dashboard in LocalStack offers streamlined testing for cloud applications, enabling you to simulate server errors, service outages, regional disruptions, and network latency with ease, ensuring your app is ready for real-world challenges.
-The dashboard uses [LocalStack Chaos API]({{< ref "chaos-api" >}}) under the hood to offer a set of customizable templates that can be seamlessly integrated into any automation workflows.
+The dashboard uses [LocalStack Chaos API](/aws/capabilities/chaos-engineering/chaos-api) under the hood to offer a set of customizable templates that can be seamlessly integrated into any automation workflows.
diff --git a/src/content/docs/aws/capabilities/config/multi-account-setups.md b/src/content/docs/aws/capabilities/config/multi-account-setups.md
index 1480ad5e..a65dd2e8 100644
--- a/src/content/docs/aws/capabilities/config/multi-account-setups.md
+++ b/src/content/docs/aws/capabilities/config/multi-account-setups.md
@@ -12,7 +12,7 @@ See [this issue](https://github.com/localstack/localstack/issues/7041) for more
LocalStack ships with multi-account support which allows namespacing based on AWS account ID.
LocalStack uses the value in the AWS Access Key ID field for the purpose of namespacing over account ID.
-For more information, see [Credentials]({{< ref "credentials" >}}).
+For more information, see [Credentials](/aws/capabilities/config/credentials).
The Access Key ID field can be configured in the AWS CLI in multiple ways: please refer to [AWS CLI documentation](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-precedence).
diff --git a/src/content/docs/aws/capabilities/config/podman.md b/src/content/docs/aws/capabilities/config/podman.md
index 5f449e87..86582a71 100644
--- a/src/content/docs/aws/capabilities/config/podman.md
+++ b/src/content/docs/aws/capabilities/config/podman.md
@@ -20,7 +20,7 @@ From the Podman docs:
To run `localstack`, simply aliasing `alias docker=podman` is not enough, for the following reasons:
- `localstack` is using [docker-py](https://pypi.org/project/docker/) which requires a connection to `/var/run/docker.sock`
-- Lambda requires mounting the Docker socket `/var/run/docker.sock` into the container (see [Lambda providers]({{< ref "user-guide/aws/lambda" >}})).
+- Lambda requires mounting the Docker socket `/var/run/docker.sock` into the container (see [Lambda providers](/aws/services/lambda)).
Here are several options on running LocalStack using podman:
diff --git a/src/content/docs/aws/capabilities/event-studio.md b/src/content/docs/aws/capabilities/event-studio.md
deleted file mode 100644
index a91536ce..00000000
--- a/src/content/docs/aws/capabilities/event-studio.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Event Studio
-description: Event Studio allows you to record, trace, debug and replay any events exchanged between AWS services.
-template: doc
----
-
-## Introduction
-
-Event Studio allows users to view, collect, and inspect data exchanges, including event payloads and metadata, between AWS services.
-It enhances system observability by displaying the data exchanged at every stage, facilitating clear understanding of event flows.
-It further centralizes debugging by enabling event replay at any system stage for detailed analysis and troubleshooting.
-In addition, it serves as a single point of truth to understand potential errors, service configuration mismatches and IAM permission issues.
-
-With Event Studio, you can:
-
-- Observe and understand the flow of events through your system.
-- Replay events to troubleshoot AWS services involved in your workflow.
-- Identify errors and obtain detailed information for corrections.
-- Get immediate feedback on any misconfigurations in your services.
-- Gain insights into IAM policies and detect missing permissions.
-- Enhance event contexts for advanced flow tracing.
-
-{{< callout >}}
-Event Studio is offered as a **preview** feature and is under active development.
-{{}}
-
-## Installation
-
-To install Event Studio, start your LocalStack container with your `LOCALSTACK_AUTH_TOKEN`:
-
-{{< command >}}
-$ export LOCALSTACK_AUTH_TOKEN=...
-$ localstack start
-{{< / command >}}
-
-Event Studio is available as a LocalStack Extension.
-To install it, use the `extensions` sub-command in the `localstack` CLI.
-Run the following command to install Event Studio:
-
-{{< command >}}
-$ localstack extensions install localstack-extension-event-studio
-{{< / command >}}
-
-Check the LocalStack logs for Event Studio output, where you should see logs like:
-
-```bash
-localstack-main | 2024-11-21T08:47:25.688 INFO --- [ MainThread] l.e.patterns.webapp : eventstudio extension available at http://localhost.localstack.cloud:4566/_extension/eventstudio
-localstack-main | 2024-11-21T08:47:25.694 INFO --- [ MainThread] l.e.patterns.webapp : eventstudio extension available at http://eventstudio.localhost.localstack.cloud:4566
-localstack-main | 2024-11-21T08:47:25.858 INFO --- [ady_monitor)] eventstudio.extension : Extension Loaded
-localstack-main | Ready.
-```
-
-You can navigate to **https://eventstudio.localhost.localstack.cloud:4566** in your browser to view your events.
-
-## Features
-
-### List the local events
-
-With Event Studio, you can view a detailed list of events in your application, including event producers, types, and timestamps.
-The interface enables you to trace the flow of events, identify relationships between services, and analyze patterns for debugging or optimization.
-
-
-
-### Display the connections
-
-By clicking on the events, you can visualize the intricate relationships between AWS services in your event-driven architecture.
-Event Studio offers a clear, interactive graph that shows how different AWS services interact, making it easy to track data flow, identify bottlenecks, and debug issues.
-
-
-
-### View Event Details
-
-When you click on the service, you can drill down into the specifics of each event, including the data exchanged between services, detailed payloads, and metadata.
-Event Studio highlights errors, warnings, and potential IAM permission issues, enabling precise debugging and troubleshooting.
-This detailed view ensures complete transparency and insight into system interactions at every step.
-
-
-
-### Edit & Replay
-
-Finally, you can modify event payloads and metadata directly within the interface to test different scenarios or adjust configurations.
-Replay edited events through your system to analyze workflows, validate fixes, and ensure accurate service interactions.
-This is essential for effectively debugging complex event-driven architectures.
-
-
-
-## Supported Services
-
-The following services are supported on Event Studio:
-
-- [S3](https://docs.localstack.cloud/user-guide/aws/s3/)
-- [SQS](https://docs.localstack.cloud/user-guide/aws/services/sqs/)
-- [SNS](https://docs.localstack.cloud/user-guide/aws/sns/)
-- [DynamoDB](https://docs.localstack.cloud/user-guide/aws/dynamodb/)
-- [Lambda](https://docs.localstack.cloud/user-guide/aws/lambda/)
-- [EventBridge](https://docs.localstack.cloud/user-guide/aws/events/)
diff --git a/src/content/docs/aws/capabilities/networking/accessing-endpoint-url.mdx b/src/content/docs/aws/capabilities/networking/accessing-endpoint-url.mdx
index 343e702e..10112dfa 100644
--- a/src/content/docs/aws/capabilities/networking/accessing-endpoint-url.mdx
+++ b/src/content/docs/aws/capabilities/networking/accessing-endpoint-url.mdx
@@ -186,8 +186,10 @@ DOCKER_FLAGS="--network my-network" localstack start
# launch your container
docker run --rm it --network my-network
# then your code can access localstack at its container name (by default: localstack-main)
-{{}}
-{{}}
+```
+
+
+```bash
# create the network
docker network create my-network
# launch localstack
diff --git a/src/content/docs/aws/capabilities/web-app/stack-insights.md b/src/content/docs/aws/capabilities/web-app/stack-insights.md
index 46554945..7ca6da23 100644
--- a/src/content/docs/aws/capabilities/web-app/stack-insights.md
+++ b/src/content/docs/aws/capabilities/web-app/stack-insights.md
@@ -24,7 +24,7 @@ The data is only used to provide you with insights into the usage of LocalStack
-To start using this feature, log in to your [LocalStack account](https://app.localstack.cloud/) and start a [LocalStack instance on your local machine]({{< ref "getting-started/auth-token" >}}).
+To start using this feature, log in to your [LocalStack account](https://app.localstack.cloud/) and start a [LocalStack instance on your local machine](/aws/getting-started/auth-token).
The system will start making your events accessible on the [Stack Insights dashboard](https://app.localstack.cloud/stacks).
Click on the Stack widget to see:
diff --git a/src/content/docs/aws/integrations/app-frameworks/spring-cloud-function.mdx b/src/content/docs/aws/integrations/app-frameworks/spring-cloud-function.mdx
index 1d26c7a3..08803029 100644
--- a/src/content/docs/aws/integrations/app-frameworks/spring-cloud-function.mdx
+++ b/src/content/docs/aws/integrations/app-frameworks/spring-cloud-function.mdx
@@ -118,7 +118,7 @@ To that end, we use the "Shadow Jar" plugin.
Here's our final `build.gradle`:
-```groovy showLineNumbers=true
+```groovy showLineNumbers=true title="build.gradle"
plugins {
id "java"
id "org.jetbrains.kotlin.jvm" version '1.5.31'
@@ -210,7 +210,7 @@ In this project, we are following
[official documentation](https://docs.aws.amazon.com/lambda/latest/dg/java-logging.html#java-wt-logging-using-log4j2.8)
to setup up `src/main/resources/log4j2.xml` content.
-```xml
+```xml title="log4j2.xml"
?xml version="1.0" encoding="UTF-8"?>
@@ -246,7 +246,7 @@ spring.cloud.function.scan.packages=org.localstack.sampleproject.api
Once configured, you can use `FunctionInvoker` as a handler for your Rest API lambda function.
It will automatically pick up the configuration we have just set.
-```java
+```java title="FunctionInvoker.kt"
org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
```
@@ -276,7 +276,7 @@ Let's configure it by creating a new configuration class `JacksonConfiguration.k
`src/main/kotlin/org/localstack/sampleproject/config`:
-```kotlin
+```kotlin title="JacksonConfiguration.kt"
package org.localstack.sampleproject.config
import com.fasterxml.jackson.annotation.JsonInclude
@@ -319,9 +319,7 @@ implementations.
Let's create a small logging utility to simplify interactions with the logger
-{/*{{< highlight kotlin "linenos=table" >}}*/}
-{/* TODO: packing this into a java block for now */}
-```kotlin
+```kotlin title="Logger.kt"
package org.localstack.sampleproject.util
import org.apache.logging.log4j.LogManager
@@ -331,7 +329,6 @@ open class Logger {
val LOGGER: Logger = LogManager.getLogger(javaClass.enclosingClass)
}
```
-{/*{{< / highlight >}}*/}
### Add Request/Response utilities
@@ -404,7 +401,7 @@ To transfer data from requests into something more meaningful than JSON strings
(and back) you will be using a lot of Models and Data Transfer Objects (DTOs).
It's time to define our first one.
-```kotlin showLineNumbers
+```kotlin showLineNumbers title="SampleModel.kt"
package org.localstack.sampleproject.model
import com.fasterxml.jackson.annotation.JsonIgnore
@@ -423,7 +420,7 @@ data class SampleModel(
Let's add our first endpoints to simulate CRUD operations on previously
defined `SampleModel`:
-```kotlin showLineNumbers
+```kotlin showLineNumbers title="SampleApi.kt"
package org.localstack.sampleproject.api
import com.fasterxml.jackson.databind.ObjectMapper
@@ -476,7 +473,7 @@ We know Java's cold start is always a pain.
To minimize this pain, we will try to define a pre-warming endpoint within the Rest API.
By invoking this function every 5-10 mins we can make sure Rest API lambda is always kept in a pre-warmed state.
-```kotlin showLineNumbers
+```kotlin showLineNumbers title="ScheduleApi.kt"
package org.localstack.sampleproject.api
import com.fasterxml.jackson.databind.ObjectMapper
@@ -518,7 +515,7 @@ We can still define pure lambda functions, DynamoDB stream handlers, and so on.
Below you can find a little example of few lambda functions grouped in `LambdaApi` class.
-```kotlin showLineNumbers
+```kotlin showLineNumbers title="LambdaApi.kt"
package org.localstack.sampleproject.api
import com.amazonaws.services.lambda.runtime.events.DynamodbEvent
@@ -631,7 +628,7 @@ functions:
```
-```java
+```java title="ApplicationStack.kt"
package org.localstack.cdkstack
import java.util.UUID
@@ -706,7 +703,7 @@ class ApplicationStack(parent: Construct, name: String) : Stack(parent, name) {
```
-```hcl
+```hcl title="variables.tf"
variable "STAGE" {
type = string
default = "local"
diff --git a/src/content/docs/aws/tooling/index.md b/src/content/docs/aws/tooling/index.md
index eb178043..5ebd8ad4 100644
--- a/src/content/docs/aws/tooling/index.md
+++ b/src/content/docs/aws/tooling/index.md
@@ -4,7 +4,7 @@ description: Increase your development efficiency with LocalStack Cloud Develope
template: doc
---
-The core of LocalStack is the [cloud service emulation]({{< ref "aws" >}}).
+The core of LocalStack is the [cloud service emulation](/aws/services/).
But LocalStack also provides a variety of tools to make your life as a cloud developer easier.
With LocalStack Cloud Developer Tools you can:
@@ -13,4 +13,4 @@ With LocalStack Cloud Developer Tools you can:
* debug Lambda executions directly from your IDE
* inject LocalStack service endpoints automatically into your application
* ...
- and much more!
\ No newline at end of file
+ and much more!
diff --git a/src/content/docs/aws/tooling/lambda-tools/hot-reloading.md b/src/content/docs/aws/tooling/lambda-tools/hot-reloading.mdx
similarity index 89%
rename from src/content/docs/aws/tooling/lambda-tools/hot-reloading.md
rename to src/content/docs/aws/tooling/lambda-tools/hot-reloading.mdx
index c1e7e05e..8284cf34 100644
--- a/src/content/docs/aws/tooling/lambda-tools/hot-reloading.md
+++ b/src/content/docs/aws/tooling/lambda-tools/hot-reloading.mdx
@@ -6,6 +6,8 @@ sidebar:
order: 2
---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
## Introduction
Hot reloading (formerly known as hot swapping) continuously applies code changes to Lambda functions without manual redeployment.
@@ -14,13 +16,13 @@ Quickly iterating over Lambda function code can be quite cumbersome, as you need
LocalStack enables fast feedback cycles during development by automatically reloading your function code.
Pro users can also hot-reload Lambda layers.
-{{< callout >}}
+:::note
The magic S3 bucket name changed from `__local__` to `hot-reload` in LocalStack v2.0.
Please change your deployment configuration accordingly because the old value is an invalid bucket name.
The configuration `BUCKET_MARKER_LOCAL` is still supported.
-More information about the new Lambda provider is available under [Lambda providers]({{< ref "user-guide/aws/lambda" >}}).
-{{< /callout >}}
+More information about the new Lambda provider is available under [Lambda providers](/aws/services/lambda).
+:::
## Hot Reloading Behavior
@@ -42,7 +44,7 @@ MacOS may prompt you to grant Docker access to your target folders.
**Layer limit with hot reloading for layers:**
When hot reloading is active for a Lambda layer (Pro), the function can use at most one layer.
-{{< callout >}}
+:::note
Configuring the file sharing mechanism in Rancher Desktop or Colima distributions is necessary to enable hot reloading for Lambda.
* For Rancher Desktop it is required to set the configuration `LAMBDA_DOCKER_FLAGS=-e LOCALSTACK_FILE_WATCHER_STRATEGY=polling`.
@@ -50,7 +52,7 @@ Configuring the file sharing mechanism in Rancher Desktop or Colima distribution
More information about this behavior can be found in the following [GitHub issue.](https://github.com/localstack/localstack/issues/11415#issuecomment-2341140998)
-{{< /callout >}}
+:::
## Application Configuration Examples
@@ -70,9 +72,10 @@ First, create a watchman wrapper by using
[one of our examples](https://github.com/localstack/localstack-pro-samples/tree/master/sample-archive/spring-cloud-function-microservice/bin/watchman.sh)
Don't forget to adjust permissions:
-{{< command >}}
-$ chmod +x bin/watchman.sh
-{{< / command >}}
+
+```bash
+chmod +x bin/watchman.sh
+```
Now configure your build tool to unzip the FatJar to some folder, which will be
then mounted to LocalStack.
@@ -90,9 +93,9 @@ buildHot.dependsOn shadowJar
Now run the following command to start watching your project in a hot-reloading mode:
-{{< command >}}
-$ bin/watchman.sh src "./gradlew buildHot"
-{{< / command >}}
+```bash
+bin/watchman.sh src "./gradlew buildHot"
+```
Please note that you still need to configure your deployment tool to use
local code mounting.
@@ -107,10 +110,10 @@ We will show you how you can do this with a simple example function, taken direc
You can check out that code, or use your own lambda functions to follow along.
To use the example just do:
-{{< command >}}
-$ cd /tmp
-$ git clone git@github.com:awsdocs/aws-doc-sdk-examples.git
-{{< / command >}}
+```bash
+cd /tmp
+git clone git@github.com:awsdocs/aws-doc-sdk-examples.git
+```
#### Creating the Lambda Function
@@ -123,39 +126,39 @@ To create the Lambda function, you just need to take care of two things:
So, using the AWS example, this would be:
-{{< command >}}
+```bash
$ awslocal lambda create-function --function-name my-cool-local-function \
--code S3Bucket="hot-reload",S3Key="/tmp/aws-doc-sdk-examples/python/example_code/lambda" \
--handler lambda_handler_basic.lambda_handler \
--runtime python3.8 \
--role arn:aws:iam::000000000000:role/lambda-role
-{{< / command >}}
+```
You can also check out some of our [Deployment Configuration Examples](#deployment-configuration-examples).
We can also quickly make sure that it works by invoking it with a simple payload:
-{{< tabpane text=true persist=false >}}
-{{% tab header="AWS CLI v1" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name my-cool-local-function \
+
+
+```bash
+awslocal lambda invoke --function-name my-cool-local-function \
--payload '{"action": "increment", "number": 3}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{% tab header="AWS CLI v2" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name my-cool-local-function \
+```
+
+
+```bash
+awslocal lambda invoke --function-name my-cool-local-function \
--cli-binary-format raw-in-base64-out \
--payload '{"action": "increment", "number": 3}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{< /tabpane >}}
+```
+
+
The invocation returns itself returns:
-```json
+```bash title="Output"
{
"StatusCode": 200,
"LogResult": "",
@@ -165,7 +168,7 @@ The invocation returns itself returns:
and `output.txt` contains:
-```json
+```text
{"result":4}
```
@@ -261,15 +264,15 @@ We will check-out a simple example to create a simple `Hello World!` Lambda func
Create a new Node.js project with `npm` or an alternative package manager:
-{{< command >}}
-$ npm init -y
-{{< / command >}}
+```bash
+npm init -y
+```
Install the the [@types/aws-lambda](https://www.npmjs.com/package/@types/aws-lambda) and [esbuild](https://esbuild.github.io/) packages in your Node.js project:
-{{< command >}}
-$ npm install -D @types/aws-lambda esbuild
-{{< / command >}}
+```bash
+npm install -D @types/aws-lambda esbuild
+```
Create a new file named `index.ts`.
Add the following code to the new file:
@@ -291,7 +294,7 @@ export const handler = async (event: APIGatewayEvent, context: Context): Promise
Add a build script to your `package.json` file:
-```json
+```json title="package.json"
"scripts": {
"build": "esbuild index.ts --bundle --minify --sourcemap --platform=node --target=es2020 --outfile=dist/index.js --watch"
},
@@ -301,9 +304,9 @@ The build script will use `esbuild` to bundle and minify the TypeScript code int
You can now run the build script to create the `dist/index.js` file:
-{{< command >}}
-$ npm run build
-{{< / command >}}
+```bash
+npm run build
+```
##### Creating the Lambda Function with ESbuild
@@ -316,40 +319,40 @@ To create the Lambda function, you need to take care of two things:
Create the Lambda Function using the `awslocal` CLI:
-{{< command >}}
-$ awslocal lambda create-function \
+```bash
+awslocal lambda create-function \
--function-name hello-world \
--runtime "nodejs16.x" \
--role arn:aws:iam::123456789012:role/lambda-ex \
--code S3Bucket="hot-reload",S3Key="/absolute/path/to/dist" \
--handler index.handler
-{{< / command >}}
+```
You can quickly make sure that it works by invoking it with a simple payload:
-{{< tabpane text=true persist=false >}}
-{{% tab header="AWS CLI v1" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke \
+
+
+```bash
+awslocal lambda invoke \
--function-name hello-world \
--payload '{"action": "test"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{% tab header="AWS CLI v2" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke \
+```
+
+
+```bash
+awslocal lambda invoke \
--function-name hello-world \
--cli-binary-format raw-in-base64-out \
--payload '{"action": "test"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{< /tabpane >}}
+```
+
+
The invocation returns itself returns:
-```sh
+```bash title="Output"
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
@@ -358,7 +361,7 @@ The invocation returns itself returns:
The `output.txt` file contains the following:
-```sh
+```text
{"statusCode":200,"body":"{\"message\":\"Hello World!\"}"}
```
@@ -370,7 +373,7 @@ Change the `Hello World!` message to `Hello LocalStack!` and run `npm run build`
Trigger the Lambda once again.
You will see the following in the `output.txt` file:
-```sh
+```text
{"statusCode":200,"body":"{\"message\":\"Hello LocalStack!\"}"}
```
@@ -379,25 +382,25 @@ You will see the following in the `output.txt` file:
In this example, you can use our public [Webpack example](https://github.com/localstack-samples/localstack-pro-samples/tree/master/lambda-hot-reloading/lambda-typescript-webpack) to create a simple Lambda function using TypeScript and Webpack.
To use the example, run the following commands:
-{{< command >}}
-$ cd /tmp
-$ git clone https://github.com/localstack-samples/localstack-pro-samples.git
-$ cd lambda-hot-reloading/lambda-typescript-webpack
-{{< / command >}}
+```bash
+cd /tmp
+git clone https://github.com/localstack-samples/localstack-pro-samples.git
+cd lambda-hot-reloading/lambda-typescript-webpack
+```
##### Setting up the build
Before you can build the Lambda function, you need to install the dependencies:
-{{< command >}}
-$ yarn install
-{{< / command >}}
+```bash
+yarn install
+```
Next, you can build the Lambda function:
-{{< command >}}
-$ yarn run build
-{{< / command >}}
+```bash
+yarn run build
+```
The `build` script in the `package.json` file uses Nodemon to watch for changes in the `src` directory and rebuild the Lambda.
This is enabled using the [`nodemon-webpack-plugin`](https://www.npmjs.com/package/nodemon-webpack-plugin) plugin, which has been pre-configured in the `webpack.config.js` file.
@@ -406,34 +409,32 @@ This is enabled using the [`nodemon-webpack-plugin`](https://www.npmjs.com/packa
You can now create the Lambda function using the `awslocal` CLI:
-{{< command >}}
-$ awslocal lambda create-function \
+```bash
+awslocal lambda create-function \
--function-name localstack-example \
--runtime nodejs18.x \
--role arn:aws:iam::000000000000:role/lambda-ex \
--code S3Bucket="hot-reload",S3Key="/absolute/path/to/dist" \
--handler api.default
-{{< / command >}}
+```
Additionally, you can create a Lambda Function URL with the following command:
-{{< command >}}
-$ function_url=$(awslocal lambda create-function-url-config \
+```bash
+function_url=$(awslocal lambda create-function-url-config \
--function-name localstack-example \
--auth-type NONE | jq -r '.FunctionUrl')
-{{< / command >}}
+```
##### Trigger the Hot Reload
Before triggering the Lambda function, you can check the current response by running the following command:
-{{< command >}}
-$ curl -X GET "$function_url"
-{{< / command >}}
-
-The response should be:
-
```bash
+curl -X GET "$function_url"
+```
+
+```bash title="Output"
{"error":"Only JSON payloads are accepted"}
```
@@ -442,7 +443,7 @@ Save the file and run the last `curl` command again.
The output should now be:
-```bash
+```bash title="Output"
{"error":"Only JSON payload is accepted"}
```
@@ -450,8 +451,9 @@ You can now see that the changes are applied without redeploying the Lambda func
## Deployment Configuration Examples
-{{< tabpane lang="YAML" >}}
-{{< tab header="Serverless Framework" lang="YAML" >}}
+
+
+```yaml
custom:
localstack:
...
@@ -472,8 +474,10 @@ custom:
- testing
lambda:
mountCode: ${self:custom.stages.${opt:stage}.mountCode}
-{{< /tab >}}
-{{< tab header="AWS Cloud Development Kit (CDK)" lang="Kotlin" >}}
+```
+
+
+```kotlin
package org.localstack.cdkstack
import java.util.UUID
@@ -514,8 +518,10 @@ class ApplicationStack(parent: Construct, name: String) : Stack(parent, name) {
return Code.fromAsset(JAR_PATH)
}
}
-{{< /tab >}}
-{{< tab header="Terraform" lang="HCL" >}}
+```
+
+
+```hcl
variable "STAGE" {
type = string
default = "local"
@@ -594,25 +600,32 @@ null : var.JAR_PATH
}
}
}
-{{< /tab >}}
-{{< /tabpane >}}
+```
+
+
You can then pass `LAMBDA_MOUNT_CWD` as an environment variable to your deployment tool.
-{{< tabpane lang="bash" >}}
-{{< tab header="Serverless Framework" lang="shell" >}}
+
+
+```bash
LAMBDA_MOUNT_CWD=$(pwd)/build/hot serverless deploy --stage local
-{{< /tab >}}
-{{< tab header="AWS Cloud Development Kit (CDK)" lang="shell" >}}
+```
+
+
+```bash
STAGE=local && LAMBDA_MOUNT_CWD=$(pwd)/build/hot &&
cdklocal bootstrap aws://000000000000/$(AWS_REGION) && \
cdklocal deploy
-{{< /tab >}}
-{{< tab header="Terraform" lang="shell" >}}
+```
+
+
+```bash
terraform init && \
terraform apply -var "STAGE=local" -var "LAMBDA_MOUNT_CWD=$(pwd)/build/hot"
-{{< /tab >}}
-{{< /tabpane >}}
+```
+
+
## Share deployment configuration between different machines
@@ -625,13 +638,13 @@ These used environment variables have to be set inside the LocalStack container.
Please note that the final path, after substituting the placeholders for their values, has to be an absolute path.
-{{< callout >}}
+:::note
Please make sure the placeholder is not substituted by your shell before being sent to LocalStack.
This is mostly relevant when using the AWS CLI to create a function.
Please use string quotation marks which prevent parameter expansion in your shell.
For bash, please use single quotes `'` instead of double quotes `"` to make sure the placeholder does not get expanded before being sent to LocalStack.
-{{< /callout >}}
+:::
### Example
@@ -658,14 +671,14 @@ This will set a `HOST_LAMBDA_DIR` environment variable to the current working di
Please note that this environment variable name is arbitrary - you can use any you want, but need to refer to that variable in your templates or commands to deploy your function correctly.
You can then deploy a hot-reloading function with the following command:
-{{< command >}}
-$ awslocal lambda create-function \
+```bash
+awslocal lambda create-function \
--function-name test-function \
--code S3Bucket=hot-reload,S3Key='$HOST_LAMBDA_DIR/src' \
--handler handler.handler \
--runtime python3.12 \
--role 'arn:aws:iam::000000000000:role/lambda-ex'
-{{< / command >}}
+```
Please note the single quotes `'` which prevent our shell to replace `$HOST_LAMBDA_DIR` before the function is created.
@@ -689,9 +702,9 @@ To set up Lambda Hot Reloading via the LocalStack Web Application:
LocalStack will automatically set up the magic S3 bucket and the S3 key pointing to your specified file path.
Changes to your Lambda code locally will be reflected immediately upon saving.
-
+
## Useful Links
* [Lambda Code Mounting and Debugging (Python)](https://github.com/localstack/localstack-pro-samples/tree/master/lambda-mounting-and-debugging)
-* [Spring Cloud Function on LocalStack (Kotlin JVM)](https://github.com/localstack/localstack-pro-samples/tree/master/sample-archive/spring-cloud-function-microservice)
\ No newline at end of file
+* [Spring Cloud Function on LocalStack (Kotlin JVM)](https://github.com/localstack/localstack-pro-samples/tree/master/sample-archive/spring-cloud-function-microservice)
diff --git a/src/content/docs/aws/tooling/lambda-tools/remote-debugging.md b/src/content/docs/aws/tooling/lambda-tools/remote-debugging.mdx
similarity index 89%
rename from src/content/docs/aws/tooling/lambda-tools/remote-debugging.md
rename to src/content/docs/aws/tooling/lambda-tools/remote-debugging.mdx
index a880bbe5..dfd6d3b6 100644
--- a/src/content/docs/aws/tooling/lambda-tools/remote-debugging.md
+++ b/src/content/docs/aws/tooling/lambda-tools/remote-debugging.mdx
@@ -6,6 +6,8 @@ sidebar:
order: 3
---
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
# Overview
This guide covers remote debugging of Lambda functions with the IDEs [Visual Studio Code](https://code.visualstudio.com/) and [IntelliJ IDEA](https://www.jetbrains.com/idea/).
@@ -21,17 +23,17 @@ More examples and tooling support for local Lambda debugging (including support
* [Lambda Debug Mode (preview)](#lambda-debug-mode-preview)
* [Resources](#resources)
-{{< callout tip >}}
+:::note
Due to the ports published by the Lambda container for the debugger, it is currently only possible to debug one Lambda function at a time.
-For advanced debugging scenarios, such as those requiring multiple ports, refer to [Lambda Debug Mode (preview)]({{< relref "debugging#lambda-debug-mode-preview" >}}) section.
-{{< /callout >}}
+For advanced debugging scenarios, such as those requiring multiple ports, refer to [Lambda Debug Mode (preview)](#lambda-debug-mode-preview) section.
+:::
## Debugging Python lambdas
Lambda functions debugging used to be a difficult task.
LocalStack changes that
with the same local code mounting functionality that also helps you
-to [iterate quickly over your function code]({{< ref "user-guide/lambda-tools" >}}).
+to [iterate quickly over your function code](/aws/tooling/lambda-tools/hot-reloading).
For a simple working example of this feature, you can refer to
[our samples](https://github.com/localstack/localstack-pro-samples/tree/master/lambda-mounting-and-debugging).
@@ -41,11 +43,11 @@ There, the necessary code fragments for enabling debugging are already present.
#### Configure LocalStack for VS Code remote Python debugging
-First, make sure that LocalStack is started with the following configuration (see the [Configuration docs]({{< ref "configuration#lambda" >}}) for more information):
+First, make sure that LocalStack is started with the following configuration (see the [Configuration docs](/aws/capabilities/config/configuration#lambda) for more information):
-{{< command >}}
-$ LAMBDA_DOCKER_FLAGS='-p 19891:19891' localstack start
-{{< /command >}}
+```bash
+LAMBDA_DOCKER_FLAGS='-p 19891:19891' localstack start
+```
#### Preparing your code
@@ -116,7 +118,7 @@ Make sure to set a breakpoint in the Lambda handler code first, which can then l
The screenshot below shows the triggered breakpoint with our `'Hello from LocalStack!'` in the variable inspection view:
-
+
#### Current Limitations
@@ -137,7 +139,7 @@ You can [follow the steps in the official docs](https://www.jetbrains.com/help/p
* Add path mapping with your project files on the host and map it to the remote directory `/var/task`.
* Copy the `pip install` command, and make sure to install the correct `pydevd-pycharm` version for your PyCharm IDE.
-
+
#### Preparing your code
@@ -171,7 +173,7 @@ def wait_for_debug_client():
In the next step we create our function.
In order to debug the function in PyCharm set a breakpoint in your function, run the Remote Debug configuration and then invoke the function.
-
+
### Creating the Lambda function
@@ -183,34 +185,34 @@ To create the Lambda function, you just need to take care of two things:
So, in our [example](https://github.com/localstack/localstack-pro-samples/tree/master/lambda-mounting-and-debugging), this would be:
-{{< command >}}
-$ awslocal lambda create-function --function-name my-cool-local-function \
+```bash
+awslocal lambda create-function --function-name my-cool-local-function \
--code S3Bucket="hot-reload",S3Key="$(pwd)/" \
--handler handler.handler \
--runtime python3.8 \
--timeout 150 \
--role arn:aws:iam::000000000000:role/lambda-role
-{{< /command >}}
+```
We can quickly verify that it works by invoking it with a simple payload:
-{{< tabpane text=true persist=false >}}
-{{% tab header="AWS CLI v1" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name my-cool-local-function \
+
+
+```bash
+awslocal lambda invoke --function-name my-cool-local-function \
--payload '{"message": "Hello from LocalStack!"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{% tab header="AWS CLI v2" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name my-cool-local-function \
+```
+
+
+```bash
+awslocal lambda invoke --function-name my-cool-local-function \
--cli-binary-format raw-in-base64-out \
--payload '{"message": "Hello from LocalStack!"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{< /tabpane >}}
+```
+
+
## Debugging JVM lambdas
@@ -231,15 +233,15 @@ services:
When creating your Lambda function, set the `_JAVA_OPTIONS` environment variable like so:
-{{< command >}}
-$ awslocal lambda create-function --function-name debugfunc \
---zip-file fileb://java-handler.zip \
---handler myindex.handler \
---runtime java8.al2 \
---timeout 150 \
---role arn:aws:iam::000000000000:role/lambda-role \
---environment '{"Variables": {"_JAVA_OPTIONS": "-Xshare:off -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=0.0.0.0:5050"}}'
-{{< /command >}}
+```bash
+awslocal lambda create-function --function-name debugfunc \
+ --zip-file fileb://java-handler.zip \
+ --handler myindex.handler \
+ --runtime java8.al2 \
+ --timeout 150 \
+ --role arn:aws:iam::000000000000:role/lambda-role \
+ --environment '{"Variables": {"_JAVA_OPTIONS": "-Xshare:off -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=0.0.0.0:5050"}}'
+```
Note the `suspend=y` option here, it will delay code execution until the debugger is attached to the debugger server.
If you want to change that, simply switch to `suspend=n`.
@@ -256,13 +258,13 @@ the following content:
while [[ -z $(docker ps | grep :5050) ]]; do sleep 1; done
```
-
+
This shell script should simplify the process a bit since the debugger server is not immediately available (only once Lambda container is up).
Then create a new `Remote JVM Debug` configuration and use the script from above as a `Before launch` target:
-
+
Now to debug your Lambda function, simply click on the `Debug` icon with `Remote JVM on LS Debug` configuration selected, and then invoke your Lambda function.
@@ -391,36 +393,37 @@ exports.handler = async (event) => {
```
Create the lambda function using:
-{{< command >}}
-$ awslocal lambda create-function --function-name func1 \
+
+```bash
+awslocal lambda create-function --function-name func1 \
--code S3Bucket="hot-reload",S3Key="$(pwd)/" \
--handler myindex.handler \
--runtime nodejs14.x \
--timeout 150 \
--role arn:aws:iam::000000000000:role/lambda-role
-{{< /command >}}
+```
Now to debug your lambda function, click on the `Debug` icon with
`Attach to Remote Node.js` configuration selected, and then invoke your
lambda function:
-{{< tabpane text=true persist=false >}}
-{{% tab header="AWS CLI v1" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name func1 \
+
+
+```bash
+awslocal lambda invoke --function-name func1 \
--payload '{"hello":"world"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{% tab header="AWS CLI v2" lang="shell" %}}
-{{< command >}}
-$ awslocal lambda invoke --function-name func1 \
+```
+
+
+```bash
+awslocal lambda invoke --function-name func1 \
--cli-binary-format raw-in-base64-out \
--payload '{"hello":"world"}' \
output.txt
-{{< /command >}}
-{{% /tab %}}
-{{< /tabpane >}}
+```
+
+
## Lambda Debug Mode (Preview)
@@ -437,11 +440,11 @@ giving developers ample time to connect remote debuggers and inspect the functio
To enable Lambda Debug Mode, set the `LAMBDA_DEBUG_MODE` environment variable as shown below:
-{{< command >}}
+```bash
LAMBDA_DEBUG_MODE=1 \
LAMBDA_DOCKER_FLAGS='-p 19891:19891' \
localstack start
-{{< /command >}}
+```
When enabled, Lambda Debug Mode automatically adjusts timeouts to accommodate debugging needs:
* **Lambda Container Startup Timeout**: Provides additional time for debugger connection during container creation.
@@ -457,13 +460,16 @@ Manually setting `LAMBDA_DOCKER_FLAGS` is unnecessary when using this configurat
Here is an example of mounting a `debug_config.yaml` in your LocalStack container to start your Debug Mode:
-{{< tabpane >}}
-{{< tab header="LocalStack CLI" lang="shell" >}}
+
+
+```bash
LOCALSTACK_LAMBDA_DEBUG_MODE=1 \
LOCALSTACK_LAMBDA_DEBUG_MODE_CONFIG_PATH=/tmp/debug_config.yaml \
localstack start --volume /path/to/debug-config.yaml:/tmp/lambda_debug_mode_config.yaml
-{{< /tab >}}
-{{< tab header="Docker Compose" lang="yaml" >}}
+```
+
+
+```yaml
services:
localstack:
container_name: "${LOCALSTACK_DOCKER_NAME:-localstack-main}"
@@ -481,8 +487,9 @@ services:
- "./debug_config.yaml:/tmp/debug_config.yaml"
- "${LOCALSTACK_VOLUME_DIR:-./volume}:/var/lib/localstack"
- "/var/run/docker.sock:/var/run/docker.sock"
-{{< /tab >}}
-{{< /tabpane >}}
+```
+
+
Any change to the configuration file on your local filesystem would be automatically picked by the LocalStack container.
After debugging a Lambda function, its associated container will automatically stop.
diff --git a/src/content/docs/aws/tooling/lambda-tools/vscode-extension.md b/src/content/docs/aws/tooling/lambda-tools/vscode-extension.md
index 7c278e45..c6cc2811 100644
--- a/src/content/docs/aws/tooling/lambda-tools/vscode-extension.md
+++ b/src/content/docs/aws/tooling/lambda-tools/vscode-extension.md
@@ -6,7 +6,7 @@ sidebar:
order: 4
---
-## Introduction
+## Introduction
[LocalStack VSCode Extension](https://github.com/localstack/localstack-vscode-extension) supports deploying and invoking Python Lambda functions through [AWS SAM](https://github.com/aws/serverless-application-model) or [AWS CloudFormation](https://aws.amazon.com/cloudformation/resources/templates/).
@@ -33,13 +33,11 @@ Install the [LocalStack VSCode Extension](https://marketplace.visualstudio.com/i
You can now open the Python handler function under `app/hello_world.py`.
Click the CodeLens **Deploy Lambda function**, select the `template.yaml`, and choose a stack name such as `my-stack`.
-
-
+
Click the CodeLens **Invoke Lambda function** and pick the stack name `my-stack` and the function `hello-world-function`.
-
-
+
## Current Limitations