A couple of short thoughts:
> offer everything under one roof
To me this is THE value prop. I don't want to deal with the headache of setting up multiple providers and API services and a pandora's box of integrations just to get a straightforward project up and running. In addition, I ideally want my production software choices to mirror what I can run on my local machine. The fact I can run PostgreSQL/Redis/Ruby/Node/SSGs/whatever here, and then push it all up somewhere and expect that It Just Works is fantastic. Bonus that it's all just accessible FLOSS tooling for the most part.
> I think your beef might actually be with serverless compute and the restrictions that come with it
That is indeed a beef I have…not that there aren't good uses for FaaS architecture, but it's just generally not been anything that solves real problems I have besides simply spinning up a "boring" monolith. Certainly we can't say it's all Netlify's fault this became a big buzzword, but let's be honest: it's been a real slog to claw back recognition and mindshare that server processes are pretty cool actually, and Netlify certainly hasn't helped in this regard. You guys, Fly, Railway, and plenty of other hosting companies out there are innovating in this space, and it's truly great to see.
The differences between Deno running locally and Deno Deploy can be a bit annoying, such as not supporting npm's on Deploy yet. I expect that will improve.
My development environment is pretty light: Deno itself and VS Code. So far I haven't needed to set up a database locally, or even install any client-side Postgres tools. (The database driver is an npm library that wraps fetch.)
My biggest issue with render was lack of command line tools that allow you to do things like change env vars during builds. It was the biggest hurdle for me.
I'm rooting for you guys. I see tons of potential.
> Unlike build args, secret mounts aren’t persisted in your built image.
At runtime, Render mounts your secret file at `/etc/secrets/FILENAME` in your container. Your application can then read it like any other file on the local filesystem.
Of course, you can always store your secrets in Render environment variables and use them via ENV statements at runtime.
However, to this day, Netlify's static site product remains ahead of Render, because we haven't invested as heavily in it as other products in our portfolio. Why? Because static site hosting is now a commoditized market, and we can differentiate ourselves better elsewhere. Netlify sees this too and is changing course accordingly (based on bobfunk/Matt's comment above). I know they will be successful, and they deserve all the good things that come their way because they've materially advanced web development over the last several years.
Jared: I think your beef might actually be with serverless compute and all the restrictions that come with it, especially when providers try to force it down developers' throats as the only way to build apps. The A in JAM can (and often should) be a long running server instead of thin Lambda skins, but Netlify is a lot less guilty of pushing this architecture compared to their peer(s).