michal-stlv

> but maybe some sort of short and sweet “us vs them” comparison on the home page would make that sell easier.

You're totally right and we will fix that and improve website and readme to answer most common questions raised here including setlvio vs. cdk/pulumi/terraform

thanks

This made my day. Would love to hear how it goes if you try it - team@stelvio.dev or just open an issue.

Thanks for the encouragement!

Just to make it explicit, I (author) did not downvoted you.

Both me and sebst (co-author) tried to answer everybody and did so politely.

We respect other opinions and Stelvio (as any other thing) might and is not for everybody.

Regarding your question. Well, it depends on the size of the project. Small enough you can do anything fast. I'm working on bigger mostly serverless system on AWS and it did take lot of time to to setup everything with CDK, certainly days.

I believe it would be faster with stelvio as it offers higher level abstractions than CDK - Stelvio was born out of my frustraction with CDK, I was doing lot of things again and again, waiting long for deployments etc.

If someone is happy with CDK, then they should use CDK, it's good too, even for me much better than CF or Terraform.

But if you feel things could be even less cumbersome, with less code and faster, maybe you could give Stelvio a try.

We're not claiming we'll do everything for everybody, we have our opinions and Stelvio is opinionated - shamefully focusing on (app) developers rather than on infrastracture focused people. https://stelvio.dev/blog/why-i-am-building-stelvio/

Thank you for your comment and wish you a good day.

Michal

Thank you for valuable feedback.

1. Not yet but coming soon.

2. Essentially yes, Stelvio is wrapper around Pulumi, using it mainly for state management and as an escape hatch in cases you might need something not supported.

3. Yes we do, there's `CloudFrontDistribution` component but it's not documented as idiomatic way is to use `Router` [1] & `S3StatitWebsite`[1] components and `custom_domains` [3].

4. Currently only v1. v2 (http) and websockets on the roadmap

5. Yes when you link resources we provide default permissions but these can be fully modified https://stelvio.dev/concepts/linking/#customizing-links If you want to link existing dynamo table that is NOT created with stelvio and link it to lambda that's currently not supported, meaning you'll not get automated permissions. Although it would be possible so we might support this use case if there's interest.

Thank you for good questions. If you have any more questions/feedback or need help hit us email at team@stelvio.dev Happy to talk.

[1] https://stelvio.dev/components/aws/cloudfront-router/ [2] https://stelvio.dev/components/aws/s3/#static-websites [3] https://stelvio.dev/components/aws/api-gateway/?h=custom#cus...

You're right, second link was broken. Fixed now. Thank you so much for taking time to check this again. If you need any help with stelvio have any more feedback to share please hit us at team@stelvio.dev Thank you again!

thanks for taking time to let us know. not sure what's going on I checked on multiple devices and it links correctly.

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

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.

I respect your point of view.

But coincidentally Stelvio was born out of frustration with CDK which I'm using at my day job for 4 years at this point:

- slow deployment: CDK is layer on top of cloud formation, it first translates to CF which is then moved to AWS and resolved/deployed there. Process is quite slow and if something goes wrong it's hard to debug, rollbacks take ages, sometimes they block due to inter-stack dependencies - CDK is still quite low level and focused on infra. You just can't create say api gateway with 3 routes each using 3 different lambdas with permission to use dynamo table in 4 lines - you an with stelvio - whatever code change you need to test you need to deploy it first which is probably slowest with CDK(compared e.g. to pulumi) then even if you run it you can't really debug it or just see prints, you need to just go thru cloudwath or other services - stelvio allows you to run lambdas in "dev mode" so you don't need to redeploy and run your lambdas locally for instant feedback and even debugging support

Having said that CDK is good tool and I'm happy that it exists as I like it much better than CF itself or Terraform. Stelvio just tries to be even better and focused on developers.

Regarding LLMs sure, problem with LLMs is not they can't generate the code but if you're willing to read and understand all of it. Stelvio is less code with higher abstractions so it's easier to comprehend.

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.

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).

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

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/

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.

Thank you! It currently supports only serverless AWS services but support for non-serverless services is on the roadmap (RDS, VPC, containers, ECS 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.

Author here. I'm happy to answer any questions. Also looking for any feedback. Thank you!

Nice writing and summary there. As an author of stelvio I felt the same. It's not that there're no tools. But none of them is covering enough AWS surface while being truly focused on Python devs. Some are general infra tools (CDK, Pulumi) focused on infra people, where python is not primary language, some are Python tools like Chalice (likely abandonded) and some are meant for Python devs but use json (Zappa).

I wrote my own thinking here https://blog.stelvio.dev/why-i-am-building-stelvio/

I 'm working hard on Stelvio hoping it can become the best tool to do infra in Python.

Btw. If you'd be willing to share more details about what you want/miss in python cloud tooling could you drop me an email at michal at stelvio.dev ? I'm happy to talk. Applies to other interested people too!

> Neat tool!

thanks! (author here not OP)

lambda/api/dynamo is just a start. I have very clear vision where i want to take this and it's not limited to lambda/api/dynamo. but these are easier to start with before you get to VPC, NAT, security groups etc. etc.

Hey, I was looking for similar tool before starting building stelvio and I found Chalice. It looked good, it's a nice tool but:

- as you mentioned, seems to be abandoned

- chalice mixes infra code with app code within the file (decorators), stelvio keeps them separate

- in chalice you configure lambdas using json. I strongly believe that everything should be done in python

- chalice is limited to lambda/api/queues, stelvio aims to go further/broader

hope this explains, happy to answer any other questions

I guess this question is not aimed at me as I'm not OP but I'll try to answer as the author of stelvio. I use CDK at my day job every day.

I like CDK, it was huge step forward compared to Cloud Formation, Terraform etc.

But I think infra tools can be still made better for developers. In stelvio you can do this:

  table = DynamoTable(
      name="todos",
      fields={
          "username": AttributeType.STRING,
          "created": AttributeType.STRING,
      },
      partition_key="username",
      sort_key='created'
  )

  api = Api("todo-api")
  api.route("POST", "/todos", handler="functions/todos.post", links=[table])
  api.route("GET", "/todos/{username}", handler="functions/todos.get")

It creates:

- DynamoDB table

- Lambda function with IAM (policy - with permissions for dynamo table, role)

- API Gateway (resources, methods, integrations, role, stage & deployment)

- CloudWatch log groups

It would be much more code in CDK.

Stelvio aims to make common things much simpler while allowing you to change details if you need to.

Hi! AFAIK in Zappa you don't define infra in Python but rather in json. Also the vision of Stelvio is broader than just serverless. I wrote about my vision here https://blog.stelvio.dev/why-i-am-building-stelvio/ if you're interested.

Hi! Good question, few reasons:

1. state management & stages - pulumi already deals with state and has support for stages (stacks) which stelvio will need.

2. there are things outside of AWS that stelvio might support later (cloudflare, etc.)

Initially I was gonna use AWS CDK which I use at work but Pulumi seems to have faster deployment and option to use other things than AWS. (Although AWS is main focus of Stelvio at leats for now)

Hello,

author of Stelvio here. Stelvio is in very early alpha far from any production use, but it's able to deploy simple API gateway, lambda and dynamo db tables with just few lines of code.

Idea is that Python devs should be able to deal with infra with Python only and minimal boilerplate - simple thing should be simple.

I'm currently working on v 0.2.0 which will have support for lambda dependencies & layers, Dynamo indexes and CORS and authorizers for API gateway.

I hope to release that in April.

For v0.3.0, stelvio will get it's own CLI too.

Any feedback is welcomed here or michal at stelvio.dev

Michal