Announcing the LocalStack Docs v2 Launch
LocalStack Docs v2 introduces a complete systems-level redesign of our documentation experience. This is not a superficial polish. It's a thoughtful overhaul of the information architecture, navigation logic, and developer workflows that underpin our docs.

LocalStack Docs v2: Introducing A New Information Architecture
At LocalStack, we believe great documentation should be more than just a place to look things up. It should feel like a system that helps you move faster, build smarter, and find exactly what you need without friction.
With the launch of Docs v2, we’re proud to introduce a complete systems-level redesign of our documentation experience. This is not a superficial polish. It’s a thoughtful overhaul of the information architecture, navigation logic, and developer workflows that underpin our docs.
For the first time, our documentation offers a unified entry-point homepage that welcomes you. Now, our users can easily jump straight into the LocalStack for AWS or Snowflake docs.
Dark mode? Light mode? You get both. 🙌🏻
A Living, Evolving Information System.
We’ve designed a scalable, modular, and developer-centric information system that supports:
- Multiple cloud platforms (AWS, Snowflake, and more coming!)
- Task-based navigation focused on developer goals
- A clear separation of capabilities, integrations, tooling, and services
- A cleaner, more responsive user interface powered by Astro Starlight
This redesign isn’t just about aesthetics. It’s about how information lives and evolves inside our docs as our platform grows.
One scalable information system, built for multi-cloud development. AWS and Snowflake users, we’ve got you covered.
RIP Old Docs. The Hidden Cost of Bad Information Architecture.
If you used our previous docs, you may remember some of the… quirks.
The old structure made it hard to find what you needed, especially if you were new to LocalStack or switching between cloud providers. Quite honestly, it felt like walking into a warehouse where every tool you’ve ever dreamed about was scattered out on the floor. Technically available, but zero points for search-ability or developer experience.
Developer pain points we heard (and felt):
- The “User Guides” section had collapsed under its own weight, cramming tools, service docs, testing guides, and deep dives into a single catch-all category with no clear logic or entry points.
- Local AWS Services lived as 100+ individual service pages nested under User Guides, turning the sidebar into a Doom Scroll Day Saga.
- We had a “Developer Hub” that sounded like an interactive portal but was actually just another folder of static docs.
- The AWS Feature Coverage table was one enormous, slow-loading page that nobody enjoyed navigating.
- Snowflake docs lived in an entirely separate domain, making cross-cloud users jump between properties.
- Navigation wasn’t responsive, mobile usability was limited, and onboarding journeys weren’t clear.
- The Reference section accidentally became our “hallway closet” where we hid miscellaneous junk we didn’t know what do to with. Useful stuff, but poorly organized and hard to discover.
We weren’t just hearing about these problems. We were experiencing them ourselves!
What’s New in Docs v2 (Phase 1)
With Phase 1 of our rollout, we focused on redefining the structural and navigational core of the documentation. Not merely by rearranging topics, but by rebuilding the information system that governs how content is accessed, grouped, and scaled.
We introduced a top-level architecture rooted in developer intent. Instead of sorting information by feature category or product team ownership, we mapped out how developers actually move through our platform. What they try first, what they search for, and what they build toward. From this, we created a modular, cloud-aware documentation experience.
To show how this plays out in practice, let’s look at the updates we made for our two currently supported providers.
AWS: From Scroll-of-Doom to Structured Simplicity
In the previous version, the AWS docs were weighed down by an unmanageable sidebar. More than 100 individual service pages were buried under the “User Guides” section, and an enormous, catch-all AWS Feature Coverage table attempted to serve too many purposes in one page.
Now, all of that has been transformed into a single, searchable Local AWS Services page. This page acts as a clean entry point, allowing developers to quickly locate the service they care about with a search bar and click into the dedicated landing page for that service.
Each AWS service page includes a new searchable and responsive AWS API coverage table. These tables are limited in visible rows for quick scanning, offering transparency into parity status. This modular structure not only cleans up the UI, but also makes it easier for us to iterate and scale documentation as support for each service evolves.
In addition, core concepts like state management, networking, IAM emulation, and container tooling are now categorized under the new Capabilities section, giving them dedicated space with clear navigation context, rather than being lumped into generic buckets. Supporting tools like the LocalStack SDK, Docker Extension, and Event Studio have their own section as well, under Tooling.
Snowflake: Multi-Cloud Flexibility in the Same System
Previously, Snowflake documentation lived on its own domain and followed a separate, inconsistent structure. That separation led to duplicated onboarding logic and an experience that felt tacked on, rather than integrated.
With Docs v2, we’ve brought Snowflake into the same system as AWS, while still honoring the differences in how Snowflake works and how Snowflake developers think.
Instead of trying to force Snowflake to have “services,” we structured the new content around Features, aligning with core data platform concepts like Iceberg Tables, Snowpipe, Dynamic Tables, and the Polaris Catalog. These features are documented individually and grouped logically so that users can explore Snowflake without the constraints of a compute-oriented mental model.
Tooling and Integration docs have been updated as well, using Snowflake-native language and workflows. Whether you’re using dbt, Airflow, Terraform, SnowSQL, or custom drivers, these topics are now organized in a way that reflects a typical data engineering stack, not just a reflection of the tools we support.
Snowflake users also benefit from the same new layout structure: a welcome page, clean left-hand nav, integrated Snowflake tutorials, Changelog visibility, and full responsiveness across devices. The experience is no longer isolated; it’s unified and designed to scale as our Snowflake support deepens.
Together, these improvements demonstrate what it means to architect documentation at the system level. We’ve created an intelligent information model that reflects how cloud products behave. And more importantly, how developers behave when using them.
A Foundational Shift in How We Scale Information.
This overhaul marks a foundational shift in how we structure, serve, and scale knowledge for LocalStack users. With a robust, modular information system in place, the documentation now:
- Aligns directly with developer workflows and goals.
- Provides clearer discoverability for both newcomers and power users.
- Adapts naturally to new cloud providers and product lines.
- Offers transparent, versioned feature tracking via GitHub-linked catalogs.
- Reduces cognitive load by removing redundancy and irrelevant content.
Bringing both AWS and Snowflake into a unified architecture takes the first step toward a fully multi-cloud documentation platform. One that is ready to grow as our customers do.
Moving Forward to Phase 2.
While Phase 1 laid the foundation, Phase 2 will bring depth.
Our next iteration will focus on a full content rewrite, mapping documentation to real-world developer workflows and aligning tutorials with more practical, use-case-driven examples. We’ll improve our sample applications with clearer categorization and metadata. We’ll enhance the discoverability of testing scenarios and walkthroughs.
One of the key priorities in Phase 2 is a complete rethinking of our Getting Started section. Right now, the structure doesn’t reflect the actual onboarding workflow of installing LocalStack, configuring your auth token, and then selecting your integration pathway (whether that’s Terraform, CDK, AWS CLI, or something else). We want to rebuild the Getting Started experience to help developers move from installation to a working local environment in minutes.
We’re not just evolving our docs. We’re evolving how developers interact with LocalStack.
Are You Ready For What Comes Next?
We’re just getting started. While Phase 1 was about structure and foundations, Phase 2 will bring more intuitive content tailored to how developers actually use LocalStack.
The bigger picture? All our efforts in our docs v2 redesign reflects how we think about developer experience at LocalStack. Great tools shouldn’t require great patience to figure out. The path from idea to implementation should feel natural. It shouldn’t feel like you’re trying to claw your way out of a retro RPG escape room. 🕹️ 🎮
We’ve built this new information architecture system to grow with you and with us. As we expand to new cloud providers and add increased parity, the documentation will evolve seamlessly without losing the clarity and structure you deserve.
Try it out and let us know what you think! The new docs are live, and we want to hear how they work for your actual workflows. What makes you move faster? What still feels clunky? Drop your thoughts in our Community Slack or open a docs GitHub issue. This new docs system is designed to evolve based on how you actually use it.
Documentation might seem like a behind-the-scenes concern, but we believe it’s foundational to everything else you build. When finding answers is effortless, you can focus on what matters: building great software.
Thank you for growing with us! See you in Phase 2.
⭐ Team Shoutouts: ⭐
A huge thank you to Brian Rinaldi, the kind of boss who doesn’t just talk strategy. He rolls up his sleeves and gets in the trenches with us. Brian led the dev work behind migrating our entire docs system to Astro Starlight and battled CSS like a true wizard. 🧙♂️
Hats off to Harsh Mishra, who also helped code our new docs v2 site from the ground up, added key features and capabilities, and made sure everything actually deployed to prod without “fun” surprises. 😎