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