[tdjsnelling]

I agree that the Heroku developer experience has been second to none. I'm a front-end & DX engineer at Northflank and we're working hard to evolve and create a next-gen iteration of the Heroku experience anchored around 12 Factor Applications in a Kubernetes/cloud native era. We're getting very close, come and see for yourself: https://northflank.com. Some key features:

* As simple as `git push` to build & deploy services

* One-click addons for Postgres, Mongo, Redis, MySQL and more

* A generous free tier to get developers on board with minimal friction

* Great out of the box observability

* The option to set up pipelines for more complex build/preview/release workflows

[btown]

> preview workflows

This please, a thousand times! We're in the midst of a complex transition from Heroku, where we relied heavily on Review Apps for getting stakeholder feedback and QA'ing complex data model changes, to a k8s-on-EKS setup where we have a Helm chart that can duplicate our normal deploy in isolated namespaces for previewing new feature branches based on Github Actions.

Our data cloning and routing needs are rather custom (white labels on top of feature branch releases, with complex fixture-loading processes), so I don't know that we'd make a great initial customer, but there are so many companies out there that should be using preview apps aggressively and don't know what they're missing. If you can make this happen in a modern environment without people needing to know what Argo and Flux are, or how to make a "for" loop in Helm, it could be a significant differentiator - and also provide a lower barrier to entry where prospective customers use you first for low-impact preview environments, then start using you for production as well.

[decidertm]

Yes, agreed with the need for improved preview workflows. For current GitOps offerings, you need a YAML degree to implement at any reasonable scale.

We currently have several customers using our API + Typescript client to provision preview environments. Create temporary databases, spawn container builds, spawn job to import dump, run migrations, deploy x micro-services, run QA and finally spin down.

The perfect situation is where the preview environments are roughly aligned with staging and production workflows. So you don't need to maintain two different systems.

Our first iteration of GitOps and template driven IaC is releasing soon. I would love to discuss your situation and how we can improve our offering. email: will at northflank.com.

(Northflank co-founder)

[ormax3]

https://northflank.com/docs/v1/application/billing/project-t...

> You can have one free project on your user account, and the resources you create within it will be limited. You will not be billed for any usage within a free project, but you must add a card to your account for verification first.

not having to add credit card info before using the free tier is one of the main reasons for Heroku being so popular with students and toy projects, truly a friction-free experience.

[jacquesm]

Heroku also started out with that generous free tier and look where we are now. Make sure your business works and is solid and protected against abusers before you start handing out free tiers because that's the hard part of anything free.

[butterfly771]

A platform that looks good (similar to railway), has added card information and is ready to try it out for some time.