Using Vercel without preview deployments

Keeping Vercel clean and silent

September 21, 2021

Vercel is a cool hosting service and is my go-to for free static hosting. Why? While I prefer the experience of GitHub Pages, Netlify and Render, Vercel is the only one to allow raw access to HTTP logs for free. GitHub Pages and Render don’t have this feature and Netlify charges a premium fee for it that’s over my budget for a small website.

And while I don’t use client-side analytics scripts (because they technically cannot be reliable), I like to have a sense of my website traffic through HTTP logs (the only proper source of truth).

Note: if you’re interested in this topic, I specifically wrote an article on how to get access to raw HTTP logs on a Vercel website. Check it out!

The problem with Vercel

Vercel works. It works well. But it doesn’t fit my workflow at all.

I like to keep things simple and minimal, and have the least amount of noise possible. Vercel likes to make things complicated, over-engineered (relative to what I’m doing with it), and noisy.

Let’s take the example of this very blog, if I wanted to host it on Vercel. The source is on GitHub, I keep my Markdown files neatly in the master branch, I render them to HTML using a dependency-based incremental build system (also known as makefile) in the gh-pages branch (could be called anything else but hey, it was once hosted on GitHub Pages after all).

I don’t need to re-render the whole site every time I deploy, which is why I commit the HTML files on a separate branch, instead of asking Vercel or any other hosting platform to compile everything from master on every deploy. This keeps things fast as fuck and low energy.

Preview deployments

By default, Vercel expects every branch to be deployable, and they have that cool feature of automatically deploying every single commit to a random URL (preview deployments). I don’t need preview deployments for my blog, but there’s no way to turn them off.

Very verbose Vercel

They also have the annoying habit of posting a comment on every GitHub PR and commit with the deployment URL by default. I hate noise and this is pure noise for me. Luckily there’s a non-intuitive way of turning it off and I’ll show you how.

Managing garbage

Finally, because each PR and commit is going to trigger a deployment with a not-so-temporary URL. This creates a lot of old, unused, garbage deployments, and Vercel doesn’t know when you don’t need them anymore and consider them garbage (for me, like, instantly, for anything that’s not the latest production build).

You can either remove them manually (sad), or you can periodically run a command that does just that for you (also sad, but less sad), and I’ll show you how.

Let’s get into it.

Turning off preview deployments (kinda)

I guess that the whole point of Vercel is to offer preview deployments, so they didn’t really consider the use case where you would want to remove them.

But if you go in your project settings, under the Git section, you can configure a “ignored build step” command.

Ignored build step

It’s a command whose exit code will determine whether Vercel will actually deploy the branch. When the command errors out (exits with a nonzero code), a new build will be triggered, but if the commands succeeds (exits with 0), this build will be ignored.

You can run Git commands there, but I like to keep it simple and just rely on the VERCEL_ENV environment variable to only allow builds on the production branch (gh-pages in my case) as defined in “production branch”.

Production branch

By using the following command, I can effectively ignore all builds that are not in the production branch.

[ "$VERCEL_ENV" != production ]

This uses the test(1) command (commonly aliased to [) to exit with an error when we’re on the production branch, in order to trigger a build.

The ignored build will still show up in your deployments list as “cancelled” deployments, and there’s no way around that, but I show you below how to garbage collect them.

Getting rid of bot comments

By default Vercel will comment on every PR and commit with the link to the deployment.

To avoid that, create a vercel.json file in every branch where you want to turn this off, with the following content:

{
  "github": {
    "silent": true
  }
}

Note: if you used the previous trick to only run builds in the production branch, you only need to add this configuration there.

Garbage collecting dangling deployments

Vercel knows to create preview deployments, but doesn’t know when to delete them. This means that you need to more or less manually delete the old preview deployments that are not needed anymore.

It usually doesn’t cause any harm to have hundreds of older versions of your website available on random public URLs that most likely only your team knows about. I just don’t like them being there in the first place.

Dangling deployments
I don't know about you, but that makes me anxious.

With the Vercel CLI, which you can install with npm install -g vercel, you can use the vercel remove command to remove deployments.

Specifically, to remove everything but deployments with an active production or preview URL, run:

vercel remove <project> --safe
Clean deployments
Now this is better!

Final thoughts

I’m not blaming Vercel for all of this, I’m happy they provide this service for free and they’re the only ones to include HTTP logs access in the free offer.

Sadly their approach to deploying websites if very far from mine, and this requires me to work around those default behaviors to have something that fits me better.

If you’re in a similar situation, I hope you found this post useful!

Want to leave a comment?

Join the discussion on Twitter or send me an email! 💌
This post helped you? Buy me a coffee! 🍻