Live data from Hacker News

Show HN: PullPreview – Deploy previews for any application, on your servers

pullpreview.com

21–30 of 38 posts

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#21
I'm not familiar enough with the gaps between Github Actions and Docker compose to understand fully what this is doing.

I recall when I deployed my first docker-compose app it took less than 5 minutes (create droplet, login, git clone, copy in my secrets, docker-compose up)

I left that droplet running ($20/month) but if I wanted to tear it down regularly then it's a short script to do so.

Now - I'm pretty green on all this stuff and it was brain-dead simple even for me. What's the gap I'm missing that you're trying to fill?

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#22
post #21

I'm not familiar enough with the gaps between Github Actions and Docker compose to understand fully what this is doing. I recall when I deployed my first docker-compose app it took less than 5 minutes (create droplet, login, git clone, copy in my secrets, docker-compose up) I left that droplet running ($20/month) but if I wanted to tear it down regularly then it's a short script to do so. Now - I'm pretty green on al…

It may be simple for you to do, but you just described having to provision a server, manually checkout your code using SSH agent forwarding or HTTPS auth, setup your environment variables, and then launch the app. And manually repeat the last steps as many times as you push to your branch.

At this point you’re the only one to know about your preview server, and you need to not forget to destroy it when you’re done.

PullPreview handles all of the synchronisation mechanism, as well as providing pretty URLs, automated SSH access to any GutHub users, source IP filtering, port firewalling, HTTPS support etc.

Plus the whole integration into GitHub so that you don’t need to retrieve the preview URL by yourself, and you get notified if anything goes wrong during the deploy, with full logs available.

That’s the gap we’re trying to fill :)

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#23
post #19

Earlier quoted context omitted.

Hello, review apps are a hot topic it seems ;) Many companies have come with their own version of the concept, which in our experience doesn’t stand well the test of time (because the person that wrote the glue code left the company or docs are lacking or setup is very complex, etc). Hence PullPreview, so that companies can delegate the burden of maintaining that workflow to us, while retaining full control over thei…

Awesome! It's always interesting to see how others solve the curly edge cases too. I struggled with figuring out when to shut down a preview (hence why it deploys in an iFrame, I track presence using websockets and shut the preview down after the user is done) Deploying on Lightsail is good too. I went with K8s and always had the intention of using some kind of VM level isolation, but (kind of) physically separate se…

> The bulk of my spin up time is spent pulling the image. I never got around to figuring out how to do a good cache for it.

With our approach you keep the same instance for the duration of a PR or branch, so you mostly incur the docker tax On the first deploy. Afterwards it will reuse the local cache.

Does that make sense?

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#24
post #23

Earlier quoted context omitted.

Awesome! It's always interesting to see how others solve the curly edge cases too. I struggled with figuring out when to shut down a preview (hence why it deploys in an iFrame, I track presence using websockets and shut the preview down after the user is done) Deploying on Lightsail is good too. I went with K8s and always had the intention of using some kind of VM level isolation, but (kind of) physically separate se…

> The bulk of my spin up time is spent pulling the image. I never got around to figuring out how to do a good cache for it. With our approach you keep the same instance for the duration of a PR or branch, so you mostly incur the docker tax On the first deploy. Afterwards it will reuse the local cache. Does that make sense?

Yep, I suppose at $5 per month or whatever the cost of the instances, that's not actually a bad price. My assumption was to spread the cost of running the previews across a fleet, but like you said, you pay the docker tax :)

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#26
post #2

Hi HN, this is our submission for PullPreview, a way to spin preview environments for any application directly from GitHub to cheap AWS Lightsail servers. No intermediary service involved. ## Context PullPreview’s main use case is for making it easier to review code in branches or pull requests, because reviews with live code are always better than code-only reviews. This means better and faster feedback from reviewe…

First off, congrats on launching! I've personally been working on something very similar for the last bit, and actually plan on launching very soon.

As other commenters have mentioned, this is a system which seems all-to-common to have built in house, and I think you've highlighted issues with that: it may be simple to get something basic working, but without a larger investment, it ends up being unstable and unmaintained.

It's been great seeing all of the similar solutions being launched over the past month, and the slight different ways that different players (you, Okteto, LayerCI, Release, FeaturePeek, etc) are approaching this issue. I see that what you have done is specifically focused on Docker, and purposely avoided Kubernetes. I think that gives you a niche space, along with Dockup (https://getdockup.com/), who I believe are taking the same approach.

I appreciate your focus on security and privacy, specifically around "can never seen your code", but I'm curious about this choice. Did you find that this was actually a concern that customers had? CI/CD platforms, which are kind of a neighbor of Continous Product Review tools (this is how I've been referring to this class of product internally), and have an implicit trust. I have not received much push-back about automated code access, and when that has been a concern, I've found that those individuals preferred to how everything in-house anyways (Gitlab, or Github Enterprise).

Do you have any sort of cost-control structure in place? Being a Github Action, I see this more as a library than a managed service, which also means you have less control/ability to monitor your users ephemeral environments, and I would hate to see the shutdown behaviour break, and suddenly ephemeral environments never go away and your user is left with an obnoxiously large AWS bill.

Overall, I love what you're doing to approach this space in a new way. If you'd like to chat about the space, my email is in my profile (I literally just added it, so hopefully it's visible :fingers-crossed:)

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#27
post #2

Hi HN, this is our submission for PullPreview, a way to spin preview environments for any application directly from GitHub to cheap AWS Lightsail servers. No intermediary service involved. ## Context PullPreview’s main use case is for making it easier to review code in branches or pull requests, because reviews with live code are always better than code-only reviews. This means better and faster feedback from reviewe…

First off, congrats on launching! I've personally been working on something very similar for the last bit, and actually plan on launching very soon. As other commenters have mentioned, this is a system which seems all-to-common to have built in house, and I think you've highlighted issues with that: it may be simple to get something basic working, but without a larger investment, it ends up being unstable and unmaint…

Hello, thanks for your comment and the great points you’ve made.

Regarding security, we do believe that it is a selling point for many companies. You might be ok granting access to Circle CI or others, but for a new kid on the block that’s more difficult. And being run as a self contained action means you are not dependent on the availability or continuity of the service you depend on.

As for misbehaving instances, this is indeed something that we thought about, and we’ll make sure this doesn’t happen in two ways: - allowing to set a max duration for an instance, and a max number of concurrent instances - having an additional trigger in the workflow file to launch a cleanup phase like every day, since GitHub actions already support cron-like tasks

I’ll send you an email a bit later as I’m currently on the go, thanks again and talk to you soon!

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#29

I would love to see a version of this for GCP an other cloud platforms (DO, Heroku, especially), would you be open to a collaboration there assuming I can code in your lingua franca?

Hello, we thought about other providers as well, can you send me an email to discuss (should be in my profile)? Thanks!

Re: Show HN: PullPreview – Deploy previews for any application, on your servers

#30
post #13

I developed something like this for my frontend team at a previous company as well. Much needed and I'm surprised not already mainstream. Love the focus on privacy/security. What's the difference from https://featurepeek.com/ ?

I didn’t know about FeaturePeek, thanks for mentioning. It looks very similar indeed. From a quick look I would say the main differences are that it doesn’t run on servers you control, and is limited to frontend code only? Also it’s pretty expensive with their per-seat pricing ;)

FeaturePeek cofounder here! Glad to see others in this space :-) Yes, our use case is mostly geared towards frontends devs getting design and product feedback from their team.

Right now we only spin up frontends (both pure static and Docker-based architectures, which you can of course point to backend services you host), and run in the public cloud (so not tied to your existing infra). By default, environments are private, so only the people you whitelist can access them.

On top of that, we overlay tools that let you comment w/ screenshots and screen recordings, and file tickets on third-party integrations.

We also have other neat usability wins, like each repo getting its own subdomain (rather than each pull request) so that you don't have to re-login to your app for each environment that spins up.

Post reply on HN