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

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 reviewers (be it clients or teammates), so that everyone can iterate faster on the feature being developed.

However in most organizations, there is only a handful of staging servers available to the developers, which are hard to keep in sync, maintain, and with complicated processes to make sure you don’t step on someone else’s code.

PullPreview solves this with ephemeral environments for any pull request or branches, just by adding a label from the GitHub UI. URLs for the deployed environments are displayed right into the GitHub UI, thanks to the integration with the Deployments API.

## How it works (spoiler: no kubernetes)

Contrary to many other solutions, PullPreview _never sees your code_, because it runs as a GitHub Action and does all the work within the GitHub Action runner. The Action automatically provisions a server in _your_ AWS account (a cheap Lightsail instance), and then boots your application using the Docker Compose file(s) that you specify. The server is automatically destroyed when the PR is merged, closed, or the label removed.

Some of the features include unlimited parallel environments, support for SSH access, source IP filtering, port filtering, seed data support, data persistence across deploys, all managed from the GitHub UI.

All of this is packaged as an Open-Source GitHub Action that can be tried right now. You can run it for free for 30 days, and after that we have two license tiers at 120€/year and 300€/year. We believe it is pretty cheap compared to rolling and maintaining your own solution in-house. It is also free for non-profits.

## Next steps

We’re looking for feedback on the idea, what could be missing, and the pricing. We are also discovering many more use cases while dogfooding our own idea. For instance, we are currently running a few services in production, continuously deployed thanks to PullPreview (e.g. pullpreview.com itself).

Hello, thanks for the kind words, and yes I think GitHub Actions have the potential to replace a large part of the current GitHub SaaS ecosystem.

There are a few demos listed in the Features section. The simplest one being a wordpress repo which shows the absolute minimal configuration required in terms of files (1 docker-compose, and 1 workflow file): https://github.com/pullpreview/demo-wordpress

You can clone that repo and fill in your AWS credentials in the Secrets section of the GitHub repository settings, and then you'll get a live environment running (like in https://github.com/pullpreview/demo-wordpress/deployments)

> because reviews with live code are always better than code-only reviews.

Always? I don't know.

The author is responsible for testing and deploying the PR, not the reviewer. Also, in devops a lot of changes affect production, so cannot be fully tested until deployment.

It sounds useful for seeing UI changes, but the closer you get to the backend, the less visibility there is.

Or in companies with "political issues" like multiple groups with boundaries between development, test, and operations.

Maybe the PullReview people can add some use cases?

Hi, thanks for commenting!

The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the development process.

It’s particularly useful for product owners who may not be coders and want to give feedback on how the feature aligns with the vision.

It’s also useful for other developers because seeing the thing live will give more context as to what the feature does and how it behaves, and as such might help reviewing the code and get reviews other than « good to merge » without any meaningful comments.

And finally it’s also very useful in making sure every dev can do a little QA on their feature in a standardised environment that runs with non-dev setting, without waiting for a staging server to be available.

The 80/20 rule most likely applies here. For some PRs you won’t need preview environments (just don’t add the label), but from my consulting gigs I have experienced more than once the need for this kind of tooling, and also witnessed more than once how many companies try to reinvent their own thing and the time they spend/waste doing so.

This is pretty neat.

Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose.

If containers are a focus perhaps you could support k8s deployment/svc manifests and compose via something like https://github.com/kubernetes/kompose

For k8s you could quickly launch a single node cluster with kind