Stelvio: Ship Python to AWS
(github.com)20 points by todsacerdoti 4 hours ago
20 points by todsacerdoti 4 hours ago
We have a handful of legacy SST Lambdas at work. We literally just use it to build a ZIP which we publish to an S3 Bucket, not much different than publishing an ECR image. It’s all Terraform from there.
Terraform in combination with Claude Code is actually quiet managable. Yes it generates much code, but you have great detail of what is actually going on, there is no hidden abstraction layers on top.
How does this compare to https://encore.dev/ or other infrastructure-inside-application-code solutions?
1) The first 2 links in the readme are 404s
2) I feel like the very first question this project needs to answer is: "Why should i use this over the official AWS CDK?" (assuming you want other people to use this). Besides maybe some nicer syntax I don't really see a reason to use this and lose all the (sometimes lacking) documentation, examples + community support that exists for CDK.
2.1) The listed benefits include "Use your favorite [...] type checker", but the example uses strings for specifying field types (vs. AWS CDK which would use enums, and is also "pure python") which immediately throws that out of the window
Thanks for having a look.
1. Links are fixed now.
2. We try to answer that hopefully better at our website https://stelvio.dev but you're right we should do it better in readme too! - Can you please be more specific regarding syntax? What you don't like or what you'd like to see? We try to have - Whole point of Stelvio is that you need to write much less code to define your infra, e.g. almost none IAM code due to our linking system. We also have "dev mode" which let's you to test/debug your lambdas locally without re-deployment - We try to have comprehensive documentation and guide covering each component. If you see something missing please can you be more specific? - Regarding community support we can't do much here other than grow community which we're trying to do. Having said that we're happy to support our users personally and answer any question or help you onboard. Just shoot email to team@stelvio.dev
2.1 many parameters/fields/properties in Stelvio have option to use either enum or string. If it's string with specific supported values it's defined as e.g. ` Literal["keys-only", "new-image", "old-image", "new-and-old-images"]` so you'll get help of IDE for auto complete as well as type-checker/linter if you use wrong value.
Thank you again for your valuable feedback. Happy to talk anytime. If you want to try Stelvio just shoot us an email and we'll help you along the way.
We also have "dev mode" which let's you to test/debug your lambdas locally without re-deployment
As does both SAM and the CDK.
https://docs.aws.amazon.com/cdk/v2/guide/testing-locally-get...
But this is 2026. You should be deploying Docker containers to Lambda and those are really easy to test locally
The manifesto link in the README still points to https://stelvio.dev/manifesto/, which should be about/manifesto/
thanks for taking time to let us know. not sure what's going on I checked on multiple devices and it links correctly.
Why would I ever use this instead of just using the CDK with Python? There is plenty of documentation and my experience is I can one shot my entire IAC with a well defined spec with ChatGPT to generate CDK code.
Yes I know AWS well enough to know whether it is correct
Seems great for really small apps where you want your resource definitions colocated with the code using them. I'd imagine the benefits start to break down as your infrastructure gets more complicated.
The bigger answer is that if you're proficient and happy with CDK or anything else to wire resource up, you're probably not going to see much (if any) benefit.
Until there is a resource you need out of the 150+ AWS services that they don’t support or a new feature of an existing resource….
Also where is this idea that it takes days to ship Python in CDK coming from?
Edit: great, getting downvoted for daring to ask the author to explain a claim. I’m noticing other people asking questions getting downvoted, too. Brigading isn’t a good look.
Stelvio's main selling point here is that you can use our higher-level components for different services and have them automatically configured.
So, you don't have to configure IAM roles, or Env vars manually, as this is handled for you through a concept called linking. https://stelvio.dev/concepts/linking/
In our experience, that alone adds a lot of productivity gains for teams.
Higher level CDK constructs do the same thing. But honestly, IAC is one of the easiest thing for LLMs to do and there is plenty of documentation to troubleshoot. There is no reason to introduce this into a company instead of using the official CDK.
It's unlikely to cover the AWS API's with 100% certainty, and I don't want to spend time trying to work out the kinks, so honestly, I'd rather just use the AWS CDK and CloudFormation.
It's not unlikely, I guarantee it will never happen. Because that's not the point.
Point is to cover most of the common cases (with escape hatch for fine-tuning in special case) and make those super easy and short to do so devs can focus on code and not infrastructure.
It's standard higher level abstraction play of doing more with less (code and time spent).
Thank you for the feedback.
Co-Author here. As long as you have trust in the underlying API of the Pulumi resources that Stelvio creates on your behalf, we have a mechanism in place that let's you fine-tune every parameter if you like. See: https://stelvio.dev/concepts/customization/
Otherwise, you can stick with Stelvio's sensible defaults if you wish.
You know you aren’t making a great case for yourself right? This is a solution looking for a problem.
Yet I have never had those problems in 8 years of working with AWS including almost 4 working at AWS ProServe (no longer there). I would never depend on a third party IAC package aside from Terraform knowing the surface area of AWS services and nit knowing if this is still going to be supported a decade from now.
I’ve used SST, Pulumi, CDK, and Terraform. I decided to stick with SST because it offers a far superior development experience. Sure, I could write IAM policies with plain CDK, but it’s more error-prone and harder to maintain. Features like linking and live lambdas just make development so much easier.
I actually think this project makes a lot of sense. It lets you get started in minutes without dealing with unnecessary details. Furthermore, you can always access the low-level Pulumi component and override whatever you need. Keep doing what you’re doing! Your project makes IaC more accessible to everyone, and that’s a good thing. I’ll be happy to try it.