Skip to content

Conversation

@quetzalliwrites
Copy link
Collaborator

@quetzalliwrites quetzalliwrites commented Feb 3, 2026

@quetzalliwrites quetzalliwrites requested review from a team and mmaureenliu February 3, 2026 22:55
@quetzalliwrites quetzalliwrites self-assigned this Feb 3, 2026
@quetzalliwrites quetzalliwrites added the documentation Improvements or additions to documentation label Feb 3, 2026
@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Feb 3, 2026

Deploying localstack-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 98a7e0f
Status: ✅  Deploy successful!
Preview URL: https://f3b8b5bc.localstack-docs.pages.dev
Branch Preview URL: https://docs-new-k8-section.localstack-docs.pages.dev

View logs

@quetzalliwrites
Copy link
Collaborator Author

Screenshot 2026-02-04 at 12 08 58 AM

fyi @simonrw @mmaureenliu keep in mind the current manual markup table we added is not responsive (normal behavior for table markup): https://6852d11b.localstack-docs.pages.dev/aws/enterprise/kubernetes/kubernetes-operator/#permissions

We need to incorporate the same table component we're using in aws API Coverage tables, such as this one:
https://docs.localstack.cloud/aws/services/account/#api-coverage

cc @HarshCasper

Copy link
Contributor

@simonrw simonrw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general a great restructuring of the Kubernetes section, thank you! However I have a few comments

tags: ["Enterprise"]
---

## Overview
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: having the first heading of the Overview section called Overview is a little repetitive. What about skipping this heading?

Copy link

@mmaureenliu mmaureenliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really LOVE this new doc!

Made some comments and suggestions and pointed a few questions to @simonrw . All in all this is great work. Thanks everybody involved! Look forward to seeing the final publication. We'll make further improvements based on user feedback but this is an amazing start.


## How the LocalStack pod works

The LocalStack pod runs the LocalStack runtime and acts as the central coordinator for all emulated AWS services within the cluster.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for current iteration, but we'll think about how to generalise the wording for all emulators we offer. I may create a placeholder Linear ticket for this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mmaureenliu are you saying this in reference of the phrase "emulated AWS services"?

Currently, my understanding is that we use the following terms for our emulators:

  • LocalStack for AWS
  • LocalStack for Azure
  • LocalStack for Snowflake


This execution mode provides stronger isolation, better security, and full integration with Kubernetes scheduling, resource limits, and lifecycle management.

The execution mode is configured using the `CONTAINER_RUNTIME` environment variable.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably more a question for @simonrw:
Better mention what's default - I assume it defaults to (or will default to from a certain version onwards) kubernetes mode?
And can refer to the when to use what mode section below.

Copy link
Contributor

@simonrw simonrw Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it defaults to docker so the user has to opt in to using the k8s executor. However only the operator sets this by default. The user has to configure the helm chart to pass it in as an envar, and of course when deploying manually this must be set.

The challenge is: the helm chart is open source so any user could deploy using it, but the executor is part of a specific tier that the user may not have subscribed to. If we set the default in the helm chart, it might send mixed confusing messages where they cannot use the executor because of a licensing mismatch. At least with the docker executor they could investigate alternative methods.

We don't really have a good story about this right now, so inputs are welcomed cc @localstack/unicorn

|---------------------|------|------|
| **DIY (YAML manifests)** | · Full control over Kubernetes configuration and resources | · Time-consuming to set up and maintain<br> · Manual updates and lifecycle management |
| **Helm chart** | · Simplifies deployment using templates and `values.yaml`<br> · Supports versioning, upgrades, and rollbacks<br> · Supports both LocalStack Community and Pro images | · Customization is limited to chart values and overrides |
| **Operator** | · Declarative, self-managed control plane<br> · Built-in validation, defaulting, and reconciliation logic | · Limited to the LocalStack Pro image only<br> · Steeper learning curve compared to Helm |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "steeper learning curve" strictly necessary? Is it always true when using an operator? The point of using the operator is simplicity and a steeper learning curve seems to defeat that purpose.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both technologies require creating a YAML manifest with some domain specific settings (i.e. the settings vary from project to project, e.g. LocalStack compared to installing the postgres operator). However the operator requires installing into the cluster, whereas helm operates from outside.

Perhaps this would be a better wording?

Suggested change
| **Operator** | · Declarative, self-managed control plane<br> · Built-in validation, defaulting, and reconciliation logic | · Limited to the LocalStack Pro image only<br> · Steeper learning curve compared to Helm |
| **Operator** | · Declarative, self-managed control plane<br> · Built-in validation, defaulting, and reconciliation logic | · Limited to the LocalStack Pro image only<br> · Requires in-cluster component (controller) |

or something?


## Help & Support

LocalStack Pro (with a valid license) is the only version that provides:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It reads to me like all pro image license give k8s support, but it could just be me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, what is the correct way to write this then? should it say "enterprise"?

quetzalliwrites and others added 3 commits February 12, 2026 07:38
Co-authored-by: Simon Walker <simon.walker@localstack.cloud>
Co-authored-by: Simon Walker <simon.walker@localstack.cloud>
Updated installation instructions for LocalStack Pro and added note about customizing the chart with a values.yaml file.
quetzalliwrites and others added 3 commits February 12, 2026 12:47
Added a section on certificate issues when spawning child pods, including error details and a solution for configuring NO_PROXY.
Co-authored-by: Simon Walker <simon.walker@localstack.cloud>
Copy link
Collaborator Author

@quetzalliwrites quetzalliwrites left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, ready for your review again @mmaureenliu @simonrw @nik-localstack @localstack/unicorn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants