In the past, Himank and I spent time at several startups (~10->200 employees), where we were on customer-facing, product-oriented teams. We often found ourselves in positions where we wanted to share our environment with designer/PM/sales folks who didn't necessarily have a dev environment setup, and ngrok didn't cut it. Further, even when trying to share our environment with fellow engineers, there was always a slow down when requiring that they git stash, git pull, etc..

The solution to these pain points was either:

1) Waiting for a full staging or production deployment, which in most cases, wasn't really practical (from a cost and/or time perspective).

2) Using a static site hosting solution (Vercel, Netlify, etc..) which didn't allow us to preview full-stack changes.

At some of these companies, an infra team had tried to build something like this, however, the "preview" workflow was very different than the "production" workflow, so there were annoyances (slow builds, lack of concurrent env support, no populating staging data etc..) that made the tool hard to use. This is where Reploy comes in! Especially in the current remote landscape, being able to have as many staging environments as features is helping teams move faster by simplifying and streamlining the feature development flow.

We've put a lot of time into making this dead simple to set up. Just connect your repo, give us the commands that you run on your dev machine, and we'll spit out a live environment on a managed link. All of this configuration can be described in the `reploy.yml` file, which is essentially a simpler version of docker-compose :). And if you already have a docker-compose file, we can use that as well :).

Take a look at a demo on our site! (https://getreploy.com).

How does it work you may ask? The short answer is k8s. We schedule these environments on Kubernetes, however, we hide this from end-users so that all that they're interacting with is the Reploy configuration (just a series of commands to start up your web app). We've also curated a bunch of "runtimes" which contain common framework dependencies (reactjs, node, rails, etc..) so that if you don't want to worry about docker, you don't have to :) . And for the hardcore folks out there, we also support custom images.

A few notable features that Reploy offers (specific to the aforementioned "staging" workflow):

1) Caching of specific directories (node_modules, .bundle, etc..) -> faster builds

2) Restarts of past environments -> Let's you compare the state of different commits

3) Notifications! -> We'll notify your team when a new environment is ready or failed the build process via slack, email, etc..

4) A "setup" hook where your team can populate a database with staging data, or configure the host environment to your liking.

From a pricing angle, we're looking to charge like most CI providers. That is, we'll charge a base price per engineer/user (~$30) and prorate any additional usage over a max number of concurrent environments. On that note, we've realized that pricing for Reploy is a very interesting problem, as the types of users that are creating environments (engineers, devops teams, etc..) are not necessarily the only users getting value out of the product (PMs, for example). If you have any thoughts here, we'd love to hear them in the comments!

Feel free to request access at https://getreploy.com if you're interested in getting up and running; also happy to answer any questions at `jay [at] getreploy.com`.

Overall, very excited to be sharing this with HN, we'd love to hear your thoughts and keep the conversation going :).