We're not "trying to achieve over them" but instead we have different focus. Our focus is on developers rather than on devops people.
You can setup your infra in stelvio with much less code, almost no worry about IAM, best practices out of the box and developers workflow in mind. E.g. dev mode allows you to change your lambda code live without redeploying.
Real lambda on AWS receives a request which is then forwarded to your local dev environment to handle it and return response which is then forwarded back to real lambda.
This way you can develop and test your code without constantly redeploying.
Yeah, SST seems to be closest thing to Stelvio I guess.
I don't really think we're competitors, their focus is on JS/TS eco system. As you suggested Stelvio focuses on Python and aims to really nail down experience for deploying Python to AWS (and later potentially elsewhere). e.g. we resolve python dependencies for lambda functions and layers and package them for you etc.
In the long run we want Stelvio to be a go to tool for deploying Python (with some nice TUI and web console to make it all really smooth).
edit: forgot to mention StackQL [3], which is somewhat similar but takes a SQL-first vs python-first approach. The IaC space is about to get a lot more interesting.
The "dev mode" where you can change lambda code live is the killer feature here. The deploy-wait-test-repeat cycle is what makes serverless development so frustrating compared to local Flask/FastAPI development.
I see others asking about CDK/Pulumi comparison - I think you're right that it's less about the underlying engine and more about the abstraction level. CDK gives you cloud primitives. Stelvio (like SST for JS) gives you developer workflows.
The automatic IAM permission generation is underrated. I've spent more debugging hours on Lambda permission errors than I'd like to admit. The error messages are terrible ("AccessDeniedException" tells you nothing about which permission is missing) and the docs always show overly-permissive examples.
Question: How does the dependency resolution work for native Python packages (e.g., numpy, pandas)? Are you pre-building wheels for Lambda's Amazon Linux environment, or using something like Lambda layers with pre-compiled binaries? That's historically been one of the most annoying parts of Python + Lambda.
For lambdas or layers you can define your dependencies in requirements.txt file or as parameter as list[str]. Stelvio will then look at python version and target architecture of your lambda and will use uv or pip to get right version of the packages (matching your lambda) and deploy them. It also has intelligent cache so nothing is downloaded twice etc.
Thank you for feedback. I went with stlv to make it shorter/faster to type but maybe stelvio is just fits better as it's the actual name of the thing :) Maybe we can have both with some alias.
Thank you! It currently supports only serverless AWS services but support for non-serverless services is on the roadmap (RDS, VPC, containers, ECS etc,)
Both AWS CDK [1] and Pulumi [2] already support Python and work great, what are you trying to achieve over them?
[1] https://docs.aws.amazon.com/cdk/v2/guide/work-with-cdk-pytho...
[2] https://www.pulumi.com/docs/iac/languages-sdks/python/
Thank you for your comment.
Stelvio uses Pulumi under the hood.
We're not "trying to achieve over them" but instead we have different focus. Our focus is on developers rather than on devops people.
You can setup your infra in stelvio with much less code, almost no worry about IAM, best practices out of the box and developers workflow in mind. E.g. dev mode allows you to change your lambda code live without redeploying.
If interested I can refer you to my older article https://stelvio.dev/blog/why-i-am-building-stelvio/ which tries to explain philosophy or shorter manifesto https://stelvio.dev/about/manifesto/
Co-author here. We’re providing higher level components for easier IaC code and automate permission generation between those resources.
On top of that we also have a dev mode that lets you run your lambdas locally - while within the AWS infrastructure
>lets you run your lambdas locally - while within the AWS infrastructure
What does that mean? Are they running locally or in AWS infrastructure?
Real lambda on AWS receives a request which is then forwarded to your local dev environment to handle it and return response which is then forwarded back to real lambda.
This way you can develop and test your code without constantly redeploying.
https://stelvio.dev/concepts/stelv-dev/
https://www.youtube.com/watch?v=W6aZFqBaH1g
This sounds a lot like what SST does (which also uses Pulumi). Do you consider them a competitor?
I would guess by focusing on Python that you can provide a tighter experience than SST. Is that your plan?
Yeah, SST seems to be closest thing to Stelvio I guess.
I don't really think we're competitors, their focus is on JS/TS eco system. As you suggested Stelvio focuses on Python and aims to really nail down experience for deploying Python to AWS (and later potentially elsewhere). e.g. we resolve python dependencies for lambda functions and layers and package them for you etc.
In the long run we want Stelvio to be a go to tool for deploying Python (with some nice TUI and web console to make it all really smooth).
This looks cool, love the approach of a more "pythonic" infra as code -- have also noticed this pattern in Modal [1] and Ray [2] and all for it.
[1] https://modal.com/docs/examples/hackernews_alerts [2] https://docs.ray.io/en/latest/ray-overview/getting-started.h...
edit: forgot to mention StackQL [3], which is somewhat similar but takes a SQL-first vs python-first approach. The IaC space is about to get a lot more interesting.
[3] https://stackql.io/docs
Thank you, just had a look at modal, which I’ve not heard before. Looks useful
Nitpick - you're writing AWS IaaC in python, not shipping python code.
Stelvio focuses on Python devs deploying Python to AWS, e.g. it deals with automatically packaging dependencies for your lambda functions etc.
Not saying you can't use it with non-Python projects to deploy your infra but focus is Python devs hence assuming you're shipping Python code.
The "dev mode" where you can change lambda code live is the killer feature here. The deploy-wait-test-repeat cycle is what makes serverless development so frustrating compared to local Flask/FastAPI development.
I see others asking about CDK/Pulumi comparison - I think you're right that it's less about the underlying engine and more about the abstraction level. CDK gives you cloud primitives. Stelvio (like SST for JS) gives you developer workflows.
The automatic IAM permission generation is underrated. I've spent more debugging hours on Lambda permission errors than I'd like to admit. The error messages are terrible ("AccessDeniedException" tells you nothing about which permission is missing) and the docs always show overly-permissive examples.
Question: How does the dependency resolution work for native Python packages (e.g., numpy, pandas)? Are you pre-building wheels for Lambda's Amazon Linux environment, or using something like Lambda layers with pre-compiled binaries? That's historically been one of the most annoying parts of Python + Lambda.
Thank you for nice feedback.
For lambdas or layers you can define your dependencies in requirements.txt file or as parameter as list[str]. Stelvio will then look at python version and target architecture of your lambda and will use uv or pip to get right version of the packages (matching your lambda) and deploy them. It also has intelligent cache so nothing is downloaded twice etc.
More details here: https://stelvio.dev/components/aws/lambda/#how-installation-...
If you want to try Stelvio we're happy to give you a hand if you need or have any questions. Just shoot at team@stelvio.dev
Author here. I'm happy to answer any questions. Also looking for any feedback. Thank you!
Looks cool at first glance!
I'd prefer `stelvio` as the CLI command though. Looks much nicer than `stlv` to me and can be searched for directly.
Thank you for feedback. I went with stlv to make it shorter/faster to type but maybe stelvio is just fits better as it's the actual name of the thing :) Maybe we can have both with some alias.
I also tend to lean towards longer CLI command names. I figure everyone is aliasing their preferred shorthand anyway.
What's wrong with https://pyinfra.com/ ?
Intrinsically, nothing, I suppose, but it's very much not focused on cloud and IaC, it even says on the tin that it's more like Ansible.
Link to GitHub repo: https://github.com/stelviodev/stelvio
I haven’t had a use case yet to try this but it looks pretty sweet!
Thank you! It currently supports only serverless AWS services but support for non-serverless services is on the roadmap (RDS, VPC, containers, ECS etc,)