Deniz İrgin
@denizirgin.bsky.social
VP of Engineering - Homerun ProntoPro, Armut.com | Speaker Codefiction | Software Developer, gamer, blogger, iron maiden fan.
https://twitter.com/denizirgin
https://twitter.com/denizirgin
With this release we’ve officially graduated from RC to a full production-ready version.
📝Full Release Notes: github.com/localstack-d...
cc: @davidfowl.com
📝Full Release Notes: github.com/localstack-d...
cc: @davidfowl.com
Release LocalStack.Aspire.Hosting 9.5.2 · localstack-dotnet/dotnet-aspire-for-localstack
Stable Release - Full-featured .NET Aspire integration for LocalStack with eager service loading and Docker socket support.
🎉 Graduation to Stable
This release marks the graduation from Release Ca...
github.com
October 27, 2025 at 2:20 PM
With this release we’ve officially graduated from RC to a full production-ready version.
📝Full Release Notes: github.com/localstack-d...
cc: @davidfowl.com
📝Full Release Notes: github.com/localstack-d...
cc: @davidfowl.com
The Go team shared similar feedback 💪
Originally, the plan was to keep separate monorepos for .NET and Go because of the tooling complexity.
Looks like we might actually move to a single backend repo 💯
We’re even joking about just migrating into existing frontend mono repo😀
Originally, the plan was to keep separate monorepos for .NET and Go because of the tooling complexity.
Looks like we might actually move to a single backend repo 💯
We’re even joking about just migrating into existing frontend mono repo😀
October 11, 2025 at 4:05 PM
The Go team shared similar feedback 💪
Originally, the plan was to keep separate monorepos for .NET and Go because of the tooling complexity.
Looks like we might actually move to a single backend repo 💯
We’re even joking about just migrating into existing frontend mono repo😀
Originally, the plan was to keep separate monorepos for .NET and Go because of the tooling complexity.
Looks like we might actually move to a single backend repo 💯
We’re even joking about just migrating into existing frontend mono repo😀
And oh. my. god.
The NX team nailed the hard stuff, affected, caching, all the things that usually make you cry in monorepo 😅
In just a few hours, I moved my .NET playground repo over, tweaked the CI/CD pipeline, and it just worked.
It felt like black magic 🚀
The NX team nailed the hard stuff, affected, caching, all the things that usually make you cry in monorepo 😅
In just a few hours, I moved my .NET playground repo over, tweaked the CI/CD pipeline, and it just worked.
It felt like black magic 🚀
October 11, 2025 at 4:05 PM
And oh. my. god.
The NX team nailed the hard stuff, affected, caching, all the things that usually make you cry in monorepo 😅
In just a few hours, I moved my .NET playground repo over, tweaked the CI/CD pipeline, and it just worked.
It felt like black magic 🚀
The NX team nailed the hard stuff, affected, caching, all the things that usually make you cry in monorepo 😅
In just a few hours, I moved my .NET playground repo over, tweaked the CI/CD pipeline, and it just worked.
It felt like black magic 🚀
Lately, our backend chapter’s been deep in the monorepo rabbit hole 🕳️
The frontend folks in the company have been using NX for years, so we figured, even though we weren’t exactly fans, let’s give it a shot.
Turns out, NX actually has plugins for both .NET and Go 🤯
The frontend folks in the company have been using NX for years, so we figured, even though we weren’t exactly fans, let’s give it a shot.
Turns out, NX actually has plugins for both .NET and Go 🤯
October 11, 2025 at 4:05 PM
Lately, our backend chapter’s been deep in the monorepo rabbit hole 🕳️
The frontend folks in the company have been using NX for years, so we figured, even though we weren’t exactly fans, let’s give it a shot.
Turns out, NX actually has plugins for both .NET and Go 🤯
The frontend folks in the company have been using NX for years, so we figured, even though we weren’t exactly fans, let’s give it a shot.
Turns out, NX actually has plugins for both .NET and Go 🤯
I believe there aren't many production-ready, end-to-end examples of Native AOT Lambdas deployed via AWS .NET CDK with this kind of local setup. I hope BadgeSmith becomes a useful case study for the community 🙌
September 8, 2025 at 7:12 PM
I believe there aren't many production-ready, end-to-end examples of Native AOT Lambdas deployed via AWS .NET CDK with this kind of local setup. I hope BadgeSmith becomes a useful case study for the community 🙌
I was able to share the same CDK stack between the production deployment and the local Aspire setup, ensuring local development is as close to production as possible👇
github.com/localstack-d...
github.com/localstack-d...
badge-smith/build/BadgeSmith.CDK.Shared at master · localstack-dotnet/badge-smith
Parameter-driven AWS Lambda API for generating dynamic NuGet and GitHub package version badges with shields.io integration. Includes endpoints for test result badges and CI/CD run redirects. Design...
github.com
September 8, 2025 at 7:12 PM
I was able to share the same CDK stack between the production deployment and the local Aspire setup, ensuring local development is as close to production as possible👇
github.com/localstack-d...
github.com/localstack-d...
This project also became a production ready, fully serverless example of modern .NET development, combining:
🏎️ .NET 9 Native AOT Lambda Functions
✨ .NET Aspire Host orchestration
☁️ AWS Aspire Integrations
🧑💻 LocalStack for local development
cc: @davidfowl.com
🏎️ .NET 9 Native AOT Lambda Functions
✨ .NET Aspire Host orchestration
☁️ AWS Aspire Integrations
🧑💻 LocalStack for local development
cc: @davidfowl.com
September 8, 2025 at 7:12 PM
This project also became a production ready, fully serverless example of modern .NET development, combining:
🏎️ .NET 9 Native AOT Lambda Functions
✨ .NET Aspire Host orchestration
☁️ AWS Aspire Integrations
🧑💻 LocalStack for local development
cc: @davidfowl.com
🏎️ .NET 9 Native AOT Lambda Functions
✨ .NET Aspire Host orchestration
☁️ AWS Aspire Integrations
🧑💻 LocalStack for local development
cc: @davidfowl.com
Let's talk performance⚡
While I managed to get the cold start under 100ms, things naturally change when network calls (Nuget and Github Api, DynamoDb etc.) come into play.
Still, in stress tests running at 1,000 RPM, I observed a max memory consumption of only 60MB💪
While I managed to get the cold start under 100ms, things naturally change when network calls (Nuget and Github Api, DynamoDb etc.) come into play.
Still, in stress tests running at 1,000 RPM, I observed a max memory consumption of only 60MB💪
September 8, 2025 at 7:12 PM
Let's talk performance⚡
While I managed to get the cold start under 100ms, things naturally change when network calls (Nuget and Github Api, DynamoDb etc.) come into play.
Still, in stress tests running at 1,000 RPM, I observed a max memory consumption of only 60MB💪
While I managed to get the cold start under 100ms, things naturally change when network calls (Nuget and Github Api, DynamoDb etc.) come into play.
Still, in stress tests running at 1,000 RPM, I observed a max memory consumption of only 60MB💪
While I initially developed the project for my own needs, I built it from the ground up to be a white-label solution⚪
The deployment pipeline is reusable, and the entire CDK Stack can be deployed to any AWS Account, making it super flexible for anyone to host.
The deployment pipeline is reusable, and the entire CDK Stack can be deployed to any AWS Account, making it super flexible for anyone to host.
September 8, 2025 at 7:12 PM
While I initially developed the project for my own needs, I built it from the ground up to be a white-label solution⚪
The deployment pipeline is reusable, and the entire CDK Stack can be deployed to any AWS Account, making it super flexible for anyone to host.
The deployment pipeline is reusable, and the entire CDK Stack can be deployed to any AWS Account, making it super flexible for anyone to host.
These are baseline numbers. I still need to add HttpClient and the AWS SDKs, so I expect these figures to climb. 📈
Still, it's a strong starting point. While I'm building this for a specific need, it will be also a production-ready .NET Aspire sample🎯
Still, it's a strong starting point. While I'm building this for a specific need, it will be also a production-ready .NET Aspire sample🎯
August 26, 2025 at 3:54 PM
These are baseline numbers. I still need to add HttpClient and the AWS SDKs, so I expect these figures to climb. 📈
Still, it's a strong starting point. While I'm building this for a specific need, it will be also a production-ready .NET Aspire sample🎯
Still, it's a strong starting point. While I'm building this for a specific need, it will be also a production-ready .NET Aspire sample🎯
🎛️ Finally, fine-tune your compilation with AOT flags.
• InvariantGlobalization=true: Shrinks package size and cuts init time if you don't need culture-specific behavior.
• TrimMode=full: Enables aggressive trimming. Start with partial first to ensure stability.
• InvariantGlobalization=true: Shrinks package size and cuts init time if you don't need culture-specific behavior.
• TrimMode=full: Enables aggressive trimming. Start with partial first to ensure stability.
August 26, 2025 at 3:54 PM
🎛️ Finally, fine-tune your compilation with AOT flags.
• InvariantGlobalization=true: Shrinks package size and cuts init time if you don't need culture-specific behavior.
• TrimMode=full: Enables aggressive trimming. Start with partial first to ensure stability.
• InvariantGlobalization=true: Shrinks package size and cuts init time if you don't need culture-specific behavior.
• TrimMode=full: Enables aggressive trimming. Start with partial first to ensure stability.
🔥And prefer .NET 9 over .NET 8! The improvements for Native AOT are dramatic. I saw:
📦 ~10-15% smaller function size
⏱️ ~15 ms faster init times
🚀 Higher overall performance
I honestly can’t imagine what .NET 10 will bring
📦 ~10-15% smaller function size
⏱️ ~15 ms faster init times
🚀 Higher overall performance
I honestly can’t imagine what .NET 10 will bring
August 26, 2025 at 3:54 PM
🔥And prefer .NET 9 over .NET 8! The improvements for Native AOT are dramatic. I saw:
📦 ~10-15% smaller function size
⏱️ ~15 ms faster init times
🚀 Higher overall performance
I honestly can’t imagine what .NET 10 will bring
📦 ~10-15% smaller function size
⏱️ ~15 ms faster init times
🚀 Higher overall performance
I honestly can’t imagine what .NET 10 will bring
🐧Your environment choices have a huge impact.
• Runtime: Use AWS’s provided.al2023. I measured a ~15 ms faster init vs. the official dotnet8 runtime.
• Architecture: arm64 beats amd64. Expect a 10-15% smaller package, lower memory usage, and ~10 ms faster bootstrap.
• Runtime: Use AWS’s provided.al2023. I measured a ~15 ms faster init vs. the official dotnet8 runtime.
• Architecture: arm64 beats amd64. Expect a 10-15% smaller package, lower memory usage, and ~10 ms faster bootstrap.
August 26, 2025 at 3:54 PM
🐧Your environment choices have a huge impact.
• Runtime: Use AWS’s provided.al2023. I measured a ~15 ms faster init vs. the official dotnet8 runtime.
• Architecture: arm64 beats amd64. Expect a 10-15% smaller package, lower memory usage, and ~10 ms faster bootstrap.
• Runtime: Use AWS’s provided.al2023. I measured a ~15 ms faster init vs. the official dotnet8 runtime.
• Architecture: arm64 beats amd64. Expect a 10-15% smaller package, lower memory usage, and ~10 ms faster bootstrap.
📡My trick for OpenTelemetry: wrap it in preprocessor directives(# if ENABLE_TELEMETRY)
A compile-time flag can strip the entire dependency, cutting package size and saving ~30ms on init + ~15ms per call. I only enable it when I need to debug. Instantiate the SDK directly, NO DI
A compile-time flag can strip the entire dependency, cutting package size and saving ~30ms on init + ~15ms per call. I only enable it when I need to debug. Instantiate the SDK directly, NO DI
August 26, 2025 at 3:54 PM
📡My trick for OpenTelemetry: wrap it in preprocessor directives(# if ENABLE_TELEMETRY)
A compile-time flag can strip the entire dependency, cutting package size and saving ~30ms on init + ~15ms per call. I only enable it when I need to debug. Instantiate the SDK directly, NO DI
A compile-time flag can strip the entire dependency, cutting package size and saving ~30ms on init + ~15ms per call. I only enable it when I need to debug. Instantiate the SDK directly, NO DI
⚖️You have to make choices for performance
Microsoft.Extensions.Logging adds a ~20 ms cold start overhead. I kept it for its structured logging features, but for absolute maximum performance, fall back to the basic LambdaContext.Logger.
Microsoft.Extensions.Logging adds a ~20 ms cold start overhead. I kept it for its structured logging features, but for absolute maximum performance, fall back to the basic LambdaContext.Logger.
August 26, 2025 at 3:54 PM
⚖️You have to make choices for performance
Microsoft.Extensions.Logging adds a ~20 ms cold start overhead. I kept it for its structured logging features, but for absolute maximum performance, fall back to the basic LambdaContext.Logger.
Microsoft.Extensions.Logging adds a ~20 ms cold start overhead. I kept it for its structured logging features, but for absolute maximum performance, fall back to the basic LambdaContext.Logger.
🚨This is the most critical one for Lambda: Avoid Generic Host, Dependency Injection (ServiceCollection), and ConfigurationBuilder.
Technically they work, but the overhead is huge:
• Generic Host alone: Adds ~70-80 ms
• DIY ServiceCollection/ConfigBuilder: Still adds ~30 ms
Technically they work, but the overhead is huge:
• Generic Host alone: Adds ~70-80 ms
• DIY ServiceCollection/ConfigBuilder: Still adds ~30 ms
August 26, 2025 at 3:54 PM
🚨This is the most critical one for Lambda: Avoid Generic Host, Dependency Injection (ServiceCollection), and ConfigurationBuilder.
Technically they work, but the overhead is huge:
• Generic Host alone: Adds ~70-80 ms
• DIY ServiceCollection/ConfigBuilder: Still adds ~30 ms
Technically they work, but the overhead is huge:
• Generic Host alone: Adds ~70-80 ms
• DIY ServiceCollection/ConfigBuilder: Still adds ~30 ms
First, the fundamentals of AOT:
🔮NO Reflection, NO dynamic code. The compiler will warn you anyway.
🛠️ALWAYS use Source Generation. For JSON, regex, etc. Even outside of AOT, this is the way. It boosts performance and can cut memory allocations💡
🔮NO Reflection, NO dynamic code. The compiler will warn you anyway.
🛠️ALWAYS use Source Generation. For JSON, regex, etc. Even outside of AOT, this is the way. It boosts performance and can cut memory allocations💡
August 26, 2025 at 3:54 PM
First, the fundamentals of AOT:
🔮NO Reflection, NO dynamic code. The compiler will warn you anyway.
🛠️ALWAYS use Source Generation. For JSON, regex, etc. Even outside of AOT, this is the way. It boosts performance and can cut memory allocations💡
🔮NO Reflection, NO dynamic code. The compiler will warn you anyway.
🛠️ALWAYS use Source Generation. For JSON, regex, etc. Even outside of AOT, this is the way. It boosts performance and can cut memory allocations💡
Been so deep in .NET NativeAOT experiments, the business logic is still evolving! 🧪 But the project's technical skeleton is solid. 🏗️
I started at 250ms Init / 50MB memory, now down to just 77ms / 28MB. The package is 3.5MB zipped. 📉
Here are my insights and key takeaways 👇
I started at 250ms Init / 50MB memory, now down to just 77ms / 28MB. The package is 3.5MB zipped. 📉
Here are my insights and key takeaways 👇
August 26, 2025 at 3:54 PM
Been so deep in .NET NativeAOT experiments, the business logic is still evolving! 🧪 But the project's technical skeleton is solid. 🏗️
I started at 250ms Init / 50MB memory, now down to just 77ms / 28MB. The package is 3.5MB zipped. 📉
Here are my insights and key takeaways 👇
I started at 250ms Init / 50MB memory, now down to just 77ms / 28MB. The package is 3.5MB zipped. 📉
Here are my insights and key takeaways 👇
⏳ Waiting a few weeks for RC feedback before the full release with more features. Huge thanks to the AWS .NET Team @normj.bsky.social & @davidfowl.com for the support! 🙌
🌴 On vacation for 2 weeks, so won’t be around much. Feedback here 👇
🔗 github.com/localstack-d...
🌴 On vacation for 2 weeks, so won’t be around much. Feedback here 👇
🔗 github.com/localstack-d...
🎉 Aspire.Hosting.LocalStack Release Candidate - Community Feedback · localstack-dotnet dotnet-aspire-for-localstack · Discussion #5
I'm excited to share that Aspire.Hosting.LocalStack has reached Release Candidate (RC) status! 🎉 This integration provides a production-ready solution for local AWS development using LocalStack wit...
github.com
August 8, 2025 at 7:33 PM
⏳ Waiting a few weeks for RC feedback before the full release with more features. Huge thanks to the AWS .NET Team @normj.bsky.social & @davidfowl.com for the support! 🙌
🌴 On vacation for 2 weeks, so won’t be around much. Feedback here 👇
🔗 github.com/localstack-d...
🌴 On vacation for 2 weeks, so won’t be around much. Feedback here 👇
🔗 github.com/localstack-d...
➕ Additionally, I've started migrating my long-maintained LocalStack Serverless demo to Aspire in a separate branch (still in progress🚛). The README isn't updated yet, but the example works👇
🔗 github.com/localstack-d...
🔗 github.com/localstack-d...
GitHub - localstack-dotnet/localstack-serverless-dotnet-demo at aspire-host
Demo project for usage of LocalStack, Serverless and .NET Core - GitHub - localstack-dotnet/localstack-serverless-dotnet-demo at aspire-host
github.com
August 8, 2025 at 7:33 PM
➕ Additionally, I've started migrating my long-maintained LocalStack Serverless demo to Aspire in a separate branch (still in progress🚛). The README isn't updated yet, but the example works👇
🔗 github.com/localstack-d...
🔗 github.com/localstack-d...
🎯 I've also updated my Aspire + OTEL + LocalStack demo from last year’s Devnot to use the new LocalStack package! 🚀
A great example of Aspire and LocalStack in action.
🔗 github.com/Blind-Strike...
A great example of Aspire and LocalStack in action.
🔗 github.com/Blind-Strike...
GitHub - Blind-Striker/dotnet-otel-aspire-localstack-demo: Showcase of OpenTelemetry in .NET with Aspire, demonstrating enhanced observability using AWS and LocalStack.
Showcase of OpenTelemetry in .NET with Aspire, demonstrating enhanced observability using AWS and LocalStack. - Blind-Striker/dotnet-otel-aspire-localstack-demo
github.com
August 8, 2025 at 7:33 PM
🎯 I've also updated my Aspire + OTEL + LocalStack demo from last year’s Devnot to use the new LocalStack package! 🚀
A great example of Aspire and LocalStack in action.
🔗 github.com/Blind-Strike...
A great example of Aspire and LocalStack in action.
🔗 github.com/Blind-Strike...