The whole tech looks kinda' cool, but this video...

I've noticed a trend where some of the dev tooling nowadays is sold almost as if it were consumer goods with the whole associated marketing behind it. This doesn't work for me, in reality actually has completely opposite effect. Give me boring well-written docs, that shows engineering that went into it, not the marketing show for teenagers.

Readers who are unfamiliar with SST would do well to read a bit about the project, the backing company, and the work they've been doing. Things have come around full-bore from serverless-only on AWS via CDK, putting huge effort into trying to make CDK fast and seamless, realizing they needed to support more than AWS and that CDK/CF are just too slow, transitioning into a Pulumi backend, supporting other clouds, and now, containers.

SST is great because they built a model for infra-as-code that gives sensible defaults out-of-the-box while preserving enormous flexibility as the architecture grows, plus great conventions around giving code access to the environment details via bindings.

Super excited to play with this.

SST (v3, ion) is awesome! Its live Lambda debugging feature totally changes the way I develop Lambda functions. It has the potential to be a cloud vendor-independent alternative to AWS Amplify Gen2.

Since SST allows you to use Pulumi code, you can code your infrastructure extensively even if some resources are not directly supported by SST itself. However, for such usage, it also has rough edges inherited from Pulumi. For instance, I encountered issues with cyclic dependencies [1] between resources and incomplete deployments. It would be great if I could run the Pulumi CLI against my SST stack.

[1]: https://github.com/pulumi/pulumi/issues/3021

Container support in SST is a great addition! But I’d really like to see support for other providers like Hetzner or VPS services in general, which often offer a more cost-effective option. [Update: seems like SST offers a lot of providers (incl. Hetzner) with varying feature sets, only most to all examples are using aws in the guide]

--

For example, SST's AWS costs example:

- AWS Fargate: 0.25 vCPU, 0.5 GB RAM, 20GB SSD: ~$13/month

- AWS Load Balancer: ~$3/month

Total: ~$17/month (rounded up)

--

In comparison, a similar (even more powerful) setup on Hetzner can be significantly more affordable:

- Hetzner VPS: 2 vCPU, 4 GB RAM, 20 GB SSD for ~ $5/month

  -- Coolify

    --- app containers

    --- load balancing

Total: around $5/month.

---

Alternatively, you can offload server management to Coolify Cloud for an extra ~ $5/month, so your Hetzner resources are dedicated solely to running your containers.

- Hetzner VPS + Coolify Cloud: ~ $10/month

You can scale vertically via Hetzner (rescale) and horizontally via Coolify (add more servers).

A more budget-friendly option like this could be valuable for users running small to medium, even larger setups !

Why not just use Pulumi? The code would be almost exactly the same?

  import * as pulumi from "@pulumi/pulumi";
  import * as aws from "@pulumi/aws";


  const cluster = new aws.ecs.Cluster("my-cluster", {
    name: "my-cluster",
  });

  export const clusterName = cluster.name;

https://www.pulumi.com/registry/packages/aws/api-docs/ecs/cl...

I'm really happy to see the SST team pushing this forward. A few months ago, I wrote about how SST is becoming a flexible framework that lets you start with a simple serverless approach and easily migrate to containers. This is my blog post in case someone is interested:

https://pablosblog.dev/posts/1

Would you trust a company whose founder dances in pajamas like Elaine Benes with an open laptop to deploy your infra? Sus, very sus.

I am wondering if this is actually a pattern that we can use to build a production system:

    const cluster = new sst.aws.Cluster("MyCluster", { vpc });

    const api = new sst.aws.ApiGatewayV2("MyApi", {})