In general, it's super useful to be able to have non-technical members of the team play with a specific feature in development, with a simulacrum of live data,

In general, it's super useful to be able to have non-technical members of the team play with a specific feature in development, with a simulacrum of live data, independent of other ongoing projects. There may be significant problems that need to be addressed, including data loss problems that make it so you can't just uncheck the feature flag in prod, and blocking staging (or worse, prod) until things can be rolled back creates a significant bottleneck. We've been experimenting with a pretty reliable way to do this in-house, though. The key is that a single Kubernetes namespace per preview app iteration contains everything your preview app needs. We have a Github action, triggered by a "preview" label on a PR and any subsequent commits, that: - builds and pushes a docker image with a dedicated tag - within the specific preview namespace named after the PR ID, spins up and seeds with test data (in our case, a sanitized subset of production) a dedicated database statefulset - runs the Helm chart that we use for production, but against this specific preview namespace, with this specific image tag, and overriding our normal ingress domain with one specific to this preview app Then when the label is removed, we drop the namespace and reclaim all resources. "Rebasing" off later data, or if reviving a stale PR, is as simple as removing and re-adding the label.