Launch HN: Reploy (YC S20) – Instant fullstack staging environments for web apps
84 comments
Here comes the elephant in the room. Please take it kindly since I'm trying to make constructive feedback.
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?
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?
We use Heroku Review Apps as well. We are considering moving to AWS, and one thing that was holding us up was that setting up review apps in AWS would require some extra work (it's not impossible but definitely not as easy as Review Apps). So I can definitely see how a tool like this can have value if you're _not_ on Heroku.
Thanks for chiming in. We're also looking to offer more than Heroku does w/ their Review apps feature :). I actually learned that the Procfile was a semi-standard on this thread, so maybe a move from Heroku isn't too difficult.
Also, happy to chat more if you're interested in the product, let me know! (you have my email ^^)
Also, happy to chat more if you're interested in the product, let me know! (you have my email ^^)
We're using Heroku where I'm at and looking to move off of it for a number of reasons. Review apps are one of the great things about Heroku, but once your team is above a certain size its most definitely not free, or even cheap.
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.
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.
YMMV, depending on your data. What we do is maintain a default staging environment and a prod environment. They are both continuously deployed off of master, so it's the same code, and we have staging populated with data that is similar to prod (just without real users... So it's just employees using it).
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.
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.
No worries, we like feedback!
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?
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?
> arguably easier than dealing with Procfiles
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?
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?
This is more of a subjective thought, but we use docker under the hood, so we support any arbitrary docker containers. Procfiles are limited in that sense.
But the argument that if you already have Procfiles in place, its easier, makes a lot of sense.
But the argument that if you already have Procfiles in place, its easier, makes a lot of sense.
I believe a Procfile on Heroku is used for Dockerfile-based apps, though the `heroku.yml` takes precedence if that is available.
I have seen this problem very closely across multiple firms and environments.
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.
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.
Hi! Very interesting points: addressed them below.
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!
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!
> 1. (c)
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
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
I can resonate with point one. Having built a few internal apps, its always tricky to have representative data for you staging env.
It even becomes exponentially more difficult when dealing with multiple data sources and APIs.. some mock sandbox mode for this would be a superpower.
It's interesting to see this, a couple of months ago I was discussing this idea with a co-worker, we agreed it would be very nice to have it, but costly to build/maintain.
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.
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.
To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed.
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 :)).
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 :)).
> To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed.
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.
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.
Right now, we support branch-level commits as well. That is, you can add a specific branch that Reploy spins up environments on (in addition to open PRs). For any branch or PR that reploy is handling, you can "restart" previous commits to do comparisons.
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.
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.
Sounds reasonable, I'll keep an eye on Reploy for the future.
Thanks for answering.
Thanks for answering.
My memory might not be serving me right, but are there 3-4 of these types of companies in YC currently?
We know of another company in a previous batch that does have a similar offering. This is definitely a growing space!
Actually, according to my count, there are 9 other companies in this space that offer deploy environments as a service, in addition to 6 platforms that also offer this functionality as part of the platform.
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.
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.
Yeah this is definitely interesting. We built this because there's so much room for innovation. Sure, there are a few people that offer staging envs, but just looking at the diversity on this thread, there's clearly not a single player that's taken over the market.
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.
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've seen a few of these "we run docker compose for every PR" solutions - did extensive research for our own company before building it internally using a slack bot.
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)
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)
Hi there, for sure! I'll put these companies in buckets:
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!
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 founder)
* 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.
* 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.
Sorry if my assumptions were incorrect in the above post; and likewise, big fans of Render's offerings :) .
Feel free to add an open source version this I created:
https://gitlab.com/Rodeoclash/StageHand
https://gitlab.com/Rodeoclash/StageHand
Thanks for the https://releaseapp.io shout out! Reploy looks like a copy of what we are doing. Game on.
I'm trying to give you the benefit of the doubt here, but trying to make a point that a new product "copied what [you] are doing" just seems inappropriate. Is there perhaps a better way that this could have been phrased?
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".
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".
Yeah, maybe I should have said, Reploy is going after the same problem in a similar way? I wasn’t trying to imply they copied what we are doing but the approach to solving the problem is very similar.
I’m a co-founder of Release. We can create/manage all envs from static builds with a single backend to production of very complicated apps.
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.
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 definitely agree. The space being validated is a fantastic thing (I have also been building a product in the space). I believe this space is big enough for multiple participants, each solving the same problem in slightly different ways.
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.
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.
Definitely understand where tommy is coming from. From a timeline perspective, we are "copying release", but better put: we're working on the same thing :).
How do you compare with LayerCI (https://layerci.com/)?
The end result is ~similar, but their configuration is a little more involved and isn't as simple as "give us the commands in your dev environment".
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.
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.
In my opinion the syntax of layerci is relatively simple as someone coming from docker, and does basically boil down to "give us the commands you use to deploy"
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
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
Hi!
> 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.
> 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.
Looks interesting but seems like it mainly fits with a docker style deployment? Does this also work with serverless tech?
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
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
Most of our users are using Reploy for the concept of "Preview Environments". That is, being able to view the environment before a merge happens.
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.
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.
Yep! that is exactly what our system also does. QA sign off and automated tests run against our preview env. We aren't pushing PRs to prod.
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.
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
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.
The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.
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
Hello! I'm slightly confused here, but I do agree with your statements.
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.
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.
Very interesting. I'm actually looking at building something like this currently (for internal usage).
How does this work with things like databases, user login, etc?
How does this work with things like databases, user login, etc?
These are actually things that our current customers have run into; our solution is reasonably generic. I've touched at your points below.
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).
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).
Just a tip: always have your domain start with the brand name. “Get___” “try___” “by___” etc are terrible because when a user is searching to quickly go to your domain, they’ll type your brand name first (as that’s what will come to mind).
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.
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.
Seems you're using Chrome, which autocomplete in the URL bar really sucks (probably on purpose)
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.
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.
Majority of people use Chrome. So it’s a very valid tip regardless of what browser I use.
Appreciate the tip! We actually have a domain with reploy__.com, but aren't using it. We'll set that up!
At my previous job, we made pr-merger[0] which is a little utility that allows you to merge all possibly mergeable open pull requests in your GitHub repository. Using this tool, we always build a full stack preview of our app before merging things to master branch.
[0] https://github.com/cloudaper/pr-merger
[0] https://github.com/cloudaper/pr-merger
This is pretty neat! Does pr-merger handle the deployment itself? From reading the docs, it seems like the tool merges a bunch of PRs into a single branch, correct?
I'm curious what the whole workflow looks like.
I'm curious what the whole workflow looks like.
We have something like this internally. It is useful in general, but not cheap for large systems - even large k8s clusters can get full if you have dozens of PRs open.
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.
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.
Ahh yes. We've spoken to some companies that have existing helm charts that they'd like to use with Reploy. Is this what you're referring to?
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.
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.
Cool idea and the video is a great overview of how it works so kudos on a job well done there!
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!
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!
Hi there, yes this was discussed in a couple threads! Happy to answer any other questions you have :) .
Struggling to understand what languages/environments you support.
I saw node.js in a build file in the docs but no other information.
Who is this for? What can I support?
I saw node.js in a build file in the docs but no other information.
Who is this for? What can I support?
Sorry for the delay here. A list of runtimes is at the bottom of this doc (https://docs.getreploy.com/docs/fields), but notably, we support arbitrary docker images.
That is, if you specify `image: node`, we'll pull from the public node image on docker hub: https://hub.docker.com/_/node/
That is, if you specify `image: node`, we'll pull from the public node image on docker hub: https://hub.docker.com/_/node/
Great stuff! I'd love to use something like this at work.
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
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
Ah, good question! We've spent some time at larger tech companies, and realized that when you have many distributed teams, you can actually run Reploy with smaller subsets of your stack, and treat external dependencies like you would for external providers.
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.
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.
I've implemented this same system in two companies throughout my career so far. Take that as some validation.
How do you plan to handle the data layer?
How do you plan to handle the data layer?
Hi there! That's awesome, would love to keep the conversation going :)
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?
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?
Quite similar to render.com or ?
Similar to https://vercel.com/docs/v2/git-integrations/vercel-for-githu... as well
I 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
I 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
I think this might also have to do with timing. As in, this "per-PR" iteration model is now becoming popular. In our minds, after CI/CD, the next thing to automate are ~full deployments.
Runnable did this and got acquired by MuleSoft. Heroku also has this feature. Vercel is less comparable since it's only for serverless. Can you link to your project?
Ok had a better look and this seems entirely focused on the dev experience, no plans for production hosting?
Not in the near future. We've realized that the "staging" workflow is quite different than production, and companies like Render, Heroku, etc.. are missing a few key features that we wished were there; so we're doubling down on per-PR staging.
Yea I had the same question. I'm interested in this but it doesn't make sense for me without the production piece or having it run on top of our own Kubernetes cluster.
We do offer an on-prem solution if you're interested. You could simply spin up a kubernetes cluster on your infra and "helm apply". Feel free to reach out at my email above if you want more specifics.
Curious what other things you're using in your stack?
The infra is scheduled on k8s. Happy to answer other specifics!
Cool stuff! Would be cool to see Reploy adopt formats other than web apps ;)
Thanks for the feedback here! We recently started looking into mobile apps through the lens of react-native-web but that's still not a priority on our roadmap yet.
Was there another specific format you had in mind?
Was there another specific format you had in mind?
I reckon you could get a few more bumper stickers on that homepage
So we finally find out what a reployer does.
- does reployer utilize a custom k8s operator?
- or does it generate deployment + service yaml's from the reployer.yaml ?
At the moment, we're generating manifests via the kubernetes API. This may change though! Take a look:
https://github.com/kubernetes/client-go
Very Nice!
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 :).