Launch HN: Reploy (YC S20) – Instant fullstack staging environments for web apps
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 intereste...
84 comments
[ 0.27 ms ] story [ 152 ms ] threadI did a similar project that I pitched to a few VCs, got negative feedback, then saw Vercel (was Zeit at the time) launch that feature. So I archived the project & OS'd it. Guess I should have pressed on
Speaking of which, I work at a larger tech company, and the webapp we work on is quite large. How does/would Reploy handle a webapp that doesn't have a simple backend? i.e. the backend is distributed among many servers
For example, maybe your team contributes to a frontend/backend regularly; you'd just staticly point the Reploy environment to other service dependencies that don't change as often.
That being said, market-wise we're targeting <200 eng companies, but definitely a cool thing to think about.
Was there another specific format you had in mind?
How does this work with things like databases, user login, etc?
re: databases, one option is pointing your Reploy environment to a common database. The other is to actually spin up a database within Reploy, where you seed data or a do a dump (pgdump, mongodump, etc..)
re: logins, we generate deterministic URLs (checkout https://docs.getreploy.com/docs/links-discovery), so you can tell your auth provider what the links will look like. (Can talk more about this if you like).
In this case “r”, but your site won’t be listed as a quick suggestion cause the domain starts with “g”.
I’d suggest “reployapp” or “reployenv” or something where brand followed by a word/descriptor.
Try Firefox and have fulltext search available for you, will make your life a lot easier. Firefox also don't have any incentives to send you to a search result page and much rather find you the correct website directly.
In my company we have been using: - Heroku Review Apps for the back-end - built with Rails, each branch/app has a separated (tiny) database - Vercel (formerly Zeit) for the front-end, which is very fast and each commit generates a separated app - which is great for comparing changes.
Important: both of these platforms allow you to run review apps for free (as in free beer) for a small team.
With that context, what advantage is there on using Deploy instead of any of these platforms?
So to touch on the Heroku argument, its easy for your team to set this up because your production environment is already on Heroku. For teams that deploy on AWS, however, setting up a `reploy.yml` file and committing it is arguably easier than dealing with Procfiles.
Re: Vercel, if a team only needs frontend apps, its definitely a good option. We offer the same service in this sense.
Overall, in your case, I do see a benefit in having both of these solutions combined. That is, being able to restart or compare a PR's state in one system probably adds value?
This is quite a strong statement — I've never had an issue with procfiles, and prefer them considering how easy they make process management. They're also even semi-standard, considering that multiple services use them (Heroku, AWS EB, etc) - contrary to the reploy.yml file.
What are the issues you've noticed with them?
But the argument that if you already have Procfiles in place, its easier, makes a lot of sense.
Also, happy to chat more if you're interested in the product, let me know! (you have my email ^^)
The biggest pain point I'd like to see solved (beyond just review apps) is the provisioning of good staging data. Ultimately we want data that looks like a subset of production data with PII scrubbed. Heroku doesn't give you an easy mechanism for getting this, and we had to sink a ton of time building this out for our specific use case.
When we spin up a review app, it generates a backup of the staging db, restores it to the review app environment. That way all review apps have essentially a copy of the default staging data. That command (backup and restore for postgres) is like two lines of code.
Useful feature suggestions for the future that already work at us: - remote debugging - database snapshots - environment cloning - actual full k8s support: larger stacks are already deployed on k8s, writing a compose file for them is a pain.
Regarding pricing, this is a good reason to use Reploy! Because all of the scheduling is happening behind the scenes, we have the flexibility to offer teams a more predictable pricing model.
I've been watching this space closely, as my org is one of the competitors (https://www.tugboat.qa/) that has been around for a few years. We started out as an internal tool in a development agency in 2012, and released this service as a product in 2016.
It's interesting to see all the new offerings in this space in the past 12 months. There's definitely an education problem, so it's probably good for all of us that so many new services are popping up that offer this functionality, therefore drawing attention to the fact that it's even an option. But the space is getting pretty saturated at this point, which makes it more difficult for newcomers.
And from a sales perspective, rarely do we hear of a company not being interested because "we're already using x".
I see a bunch of opportunities to branch out from staging; makes the space really exciting imo.
I saw node.js in a build file in the docs but no other information.
Who is this for? What can I support?
That is, if you specify `image: node`, we'll pull from the public node image on docker hub: https://hub.docker.com/_/node/
The conclusion I got was that, we could use deterministic urls (just you like you specify `https://{repo-id}-{commit}-{service}.reploy.io`), which can get linked automatically on every PR.
Every PR could trigger an environment to be created, dropping it after it's unused for a given period of time, on every commit, you could get the environment built automatically when you get an user visiting the specific url. This way, you don't waste too many resources, I wasn't able to find how similar is this to what's implemented on Reploy.
Something I'd love to see, is a way to get mobile apps built for these specific environments, it's kind of simple for Android, but not so simple for iOS, so that if I'm trying a specific environment, I can run tests directly from the mobile apps prepared for it. Is there any plan to do this? or any trick to get a similar workflow?
What I dislike is the price per seat, as I don't see a direct correlation between the number of Github users vs the number of environments, for small companies, it tends to increase the costs a lot, which has prevented me to integrate great tools, I'd prefer something more related to the number of active environments, so that you can choose the number that works for your team.
In any case, looks promising, and of course, wish you success.
Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users?
Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing, mainly because they're hesitant about spinning up too many environments. If this seems interesting to you all, we'd be happy to chat more about pricing (as we're still figuring things out :)).
What about specific commits after the PR is closed? The use case I see it's to be able to easily test whether a previous commit has the same bug you are hitting in production.
Then you could simulate `git bisect` on real environments.
> Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users?
The React Native containers idea is an interesting one, which I wasn't aware of.
Related to native mobile apps, iOS/Android allow you to upload test versions, so that you can install the specific for your environment, another way for android could be to provide the APK file directly somewhere.
> Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing
I believe it depends on how your customers are, there are companies having decent budget for dev tools, but if you think about companies that are bootstrapping without investors, the cash available is tight, and lot's of tools to choose from.
I could see myself paying $30-$60 USD/month (you mentioned $30 per seat), but that would limit it to myself, and another collaborator, It's unlikely I'm the only one in this situation.
The idea for supporting any commit on the whole repo is interesting (and honestly, not hard to implement), definitely see the benefit there!
Re: mobile. Yeah, maybe we could push arbitrary assets to a bucket somewhere so that you could serve an android build there. We're definitely focused on the web aspect, but this is exciting wrt/ making Reploy more encompassing.
And re: pricing. Got it. If you don't mind sharing more about your team's situation, we can probably figure something out (my email's in the post). The reason we charge per seat is because its a reasonable proxy for how many environments are being spun up, and frankly we're still learning how to metricize. It'd be cool to see what your team's workflows look like.
Thanks for answering.
At my current company we have a CI/CD setup that also deploys a per-PR environment - uses terraform and gitlab pipelines to manage everything including our production deployments.
I'd use this for side projects to get things visible but not for a real production app as I'd want the deployment system to be the same between PR environments and production
In fact, in many cases, it doesn't make sense to do a full production deployment on every PR (either from a time or cost perspective).
I do, however, understand your hesitancy regarding having a different deployment structure for these previews. The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.
It's just hard to justify the validity of a preview env if the deployment is different to that of prod, the deployment and infra is part of what you test IMO.
What makes you say there needs to be a tradeoff? If you can deploy these preview environments so easily why can it not be the same for production too?I actually think this is a great sounding product. I've pushed in almost every company I've worked at in the past to have per PR environments but never actually had it working for real until my current workplace and it is fantastic. It's for sure made easier with the use of serverless and/or container
Are you implying that Reploy should also support production Deployments? If that's the case, then yes! We're also thinking in that vain more long term. I personally feel like existing solutions have their downsides, and there's a lot of room for innovation in this space :).
Regarding the tradeoff, I'm mostly referring to existing large companies that have lengthy deployment pipelines. For them, Reploy is a good solution to "preview" changes before they go into production.
> It's just hard to justify the validity of a preview env if the deployment is different to that of prod
For the "preview" use case, it often makes sense. i.e. I just wanna make sure that a button works or something. But I do agree that the production/integration-testing similarity is missing here. This is where the Reploy for production idea is strengthened.
Last point: For really big companies, there's no way that their prod infrastructure would fit into a Preview environment. This is where Reploy (only staging) proves itself being a valid product on its own.
Sorry if my thoughts are jumbled, but really appreciate the interest/questions.
Could you discuss how you are different than other (often free) offerings?
- https://www.releaseapp.io/
- https://getdockup.com/
- https://vercel.com/
- https://render.com/
- https://devcenter.heroku.com/articles/github-integration-rev...
- https://www.netlify.com/
- rolling your own using AWS SDK + spot instances + slack chatbot (our solution)
https://render.com/ These folks are a production solution and have added support for review apps. All that happens is a new deploy of the production app on every PR. There's no support for spinning up arbitrary commits, caching, etc.. Further, its not free.
https://vercel.com/, https://www.netlify.com/ Only supports frontend (and maybe serverless?)
https://www.releaseapp.io/, https://getdockup.com/ These are both more direct competitors. Dockup is no longer around I believe. Wrt/ release we have different outlooks on pricing, as they charge a large initial fee. The product itself is similar, however.
And lastly, Heroku was discussed in threads below, but the general idea is that if you're already on Heroku, using review apps makes a lot of sense! With that being said, they don't support the features I mentioned above such as, restarting runs, comparing commits, caching, etc..
Let me know your thoughts, happy to keep the conversation going!
* Render PR previews have built-in caching.
* Many of our customers use Preview Environments (currently in early access). For every PR, Render automatically spins up a complete testing environment including static sites, servers and databases that can be seeded with a hook. It's similar to Heroku's Review Apps, but a fraction of the cost.
* Render's Preview Environments are free for static sites and prorated by the second for servers and databases. Regarding pricing: we charge for actual usage (vs. a per-seat model) because previews (and consequently our own costs) rarely scale linearly with developer count.
More generally, it's great to see more activity in the space because it's a validation of our own product strategy, and there is obviously room for multiple players.
Both products operate in the same space, and are attempting to solve similar problems, but as far as I can recall Release attempts to manage all environments from dev -> production, while Reploy is specifically targeting the developer experience around managing and sharing staging environments.
The concept of dynamic staging environments is not new; I've personally built in-house solutions to solve this problem years ago, well before Release went through YC. It's not really fair to say that anyone who comes out with a similar product is "copying Release".
But, we started with the idea of Review apps for more complicated apps than heroku can do.
There are many companies trying to solve this problem in various ways, or smaller parts of it, which is good, validated the space.
I agree with the other responses; everyone is working on the same problem, but from what I've seen no one is just a copy of someone else's work.
https://gitlab.com/Rodeoclash/StageHand
I'm sure this will come as not surprise, but this makes me think immediately of Heroku Review Apps. Could you address directly why reploy is a better service than Heroku Review Apps, especially for teams that are already using Heroku?
Edit: I see Heroku Review Apps are addressed elsewhere in this thread, feel free to ignore!
That being said, it seems like they're focused on speed, as they support in memory caching, and have double down on restarting previous commits quickly.
However they also have the advantage that they can run deployments on arbitrary runtimes. It looks like reploy only works if my app fits in the runtimes that were preconfigured by you. Because of that, I can run not just my dev deployment, but something very close to my prod deployment as well (we've had multiple bugs that only show up in prod due to our build process).
And finally, their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well. The speedups are typically in the triple digits compared to a reasonably well-optimized build.
I think the differences are major enough that I wouldn't exactly characterize the end results as similar.
Full disclosure: I know the founder
> In my opinion the syntax of layerci is relatively simple
That's awesome! They've definitely built a nice product for some use cases, can't disagree with that.
> Reploy only works if my app fits in the runtimes that were preconfigured by you
Reploy actually supports any arbitrary runtime. Checkout our docs: https://docs.getreploy.com
> their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well
Makes sense; Reploy actually won't run your tests (or any other CI-esque things to that note). We're very much focused on only spinning up environments!
Overall, there is definitely overlap here. I'd argue that if someone wants to spin up a frontend, backend, db, etc., it makes a lot more sense to enumerate your `services` rather than try and serve them all in a single runtime (I think this is called a Layerfile?). I'm not sure how a use case like this would work with Layer, but that would be my hesitance in trying to set things up.
Layer seems like a great option for running long jobs to really take care of that speed up.
[0] https://github.com/cloudaper/pr-merger
I'm curious what the whole workflow looks like.
Just a few points that I would request you to dig further.
1. Quick immutable envs aren't so much of a problem for B2C apps. Particularly for B2B apps, it's not just the "run-build--pull-image--deploy--start-svc--share-url" that's the real hard part. The real hard part for B2B apps is the test data - the sane dataset which needs to be replicated as well, per environment. Nobody wants to use a test/staging DB where changes are uncontrolled. Bottomline - Immutability isn't just at the app layer, has to cover the test data and stateful parts (datastores) too.
2. What's the real value of it? One possible way to figure out hassle-to-value ratio, is the ratio of number-of-commits to number-of-builds, and the ratio of number-of-builds to any number-signifying-quality. If more builds (=> more number of envs cropping up, and brought down, that is a high rate of env churn) do not mean increased quality, then anyone choosing such a solution is really just doing it for the sake of feeling self-important or sounding smart.
One really has to be keenly tuned for the real business value, while validating fitment of such tools for the org/business.
Happy to discuss more. I have been designing/building tools like this, as a day job for quite some time.
1. For the most part, with Reploy, users either
a) Use a staging db
b) Seed their environments with fixtures or test data.
c) Do a db dump of a common db
Each of them have their own tradeoffs, which, from your knowledge of the space, are probably not worth describing in depth. The most ideal situation given your description is probably (c) because you can control what data is being seeded into each environment and introduce test data that everyone's staging env can then use.
2. I agree, but the problem here is that "any number signifying quality" isn't very easy to metricize. From our current users, Reploy is generally a no brainer. i.e. they go through the flow of having to spin up so many staging envs (or are annoyed by the lack thereof) that they use our product. In the near future, however, from a marketing/sales perspective we do want to do work to figure out who exactly is feeling the pain the most, as this is who we want to target.
What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!
Yup, that's the most sensible option but the fitment really depends on the context.
> 2.
IMHO, more thought is definitely needed, in case you want to avoid expert beginners subscribing and cancelling it after a couple of months/quarters
> What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!
Have been designing and building dev/rel/ops/maint/mon/ALM tools for the last 13 years, in large firms, SMEs and startups
How do you plan to handle the data layer?
I touched on this in another thread slightly, but the short answer is that we support a 'setup' directive where the user can populate data into the environment.
Most of our current users have a common "reploy" db that they dump into the environment on each new run. And an even simpler approach is just pointing all of your environments at a single db.
Any thoughts there? What have your experiences been like?