It’s good that multiple companies are trying to solve the problem, as it’s a big problem. I’ve not used Dockup, but from reading the docs and from other feedback I’ve heard, their solution seems like a more involved process to get running. And I think you pointed that out in your comment.
From our basic understanding of Dockup that primarily is a result of reading their documentation, it appears that the customer has to do a lot of the DevOps/AWS/Kubernetes work on their own to get things going. A big point of differentiation for us is we’re trying to automate as much of that as possible and make it accessible to developers without having to get DevOps involved (or get them involved as little as possible).
We have a solution for database and seed data that we are currently testing with customers. As far as auth'ing with 3rd parties we’ve had to solve this problem for ourselves (our integrations with Github/Bitbucket present this issue with ephemeral environments) and our approach is to take those learnings and create simple generic solutions for them. Right now we would solve that with any customer as part of our onboarding.
I’m not quite sure what challenges you had with subdomains while using Dockup. We auto-create subdomains for all your staging environments including managing dns, either in our cloud or in your AWS account. We have some documentation on how you design your architecture/app for staging environments here: https://docs.releaseapp.io/multiple-environments.
Dealing with subdomains ends up being part design issue (not hardcoding IP/host names, etc) and part using a system that can handle all the complexities around dns, and networking of your services.
We don’t have time limits on the environments. We will be adding administrative settings to allow customers to control the life-cycle of their staging environments. At this moment, they can be created manually or through a pull request. If they are created through a pull request, they are automatically removed when the pull request is merged or removed. But, this is how Release works at the moment based on customer feedback and can be adapted to your use case.
We have worked on this problem all through our careers. We are encouraged by all the companies trying to solve this issue. We feel our approach is unique in its simplicity for the end-user, but we are aware of the complexities inherent in generalizing an approach for other people. It’s hard.
I really appreciate your feedback and would love a chance to show you what we are doing and hopefully we are different and useful enough for a system as complex as yours. If you want please reach out at founders @ releaseapp .io