Netlify is popular among people who are looking for a simple platform to build and host websites, but one feature in particular gets a lot of love from developers and site-builders: Netlify Deploy Previews. There’s a good reason for this: the ability to deploy every pull request from a Git repository to create a fully-functional version of a website is pretty transformational to the development experience. If you’ve wanted the ability to have deploy previews but aren’t using Netlify as a web host, there’s good news: you can get on-demand previews of your websites via a hosting-agnostic service: Tugboat.
So what’s the big deal with deploy previews, anyway? Why do developers and site builders love them so much?
Well, lots of reasons! Everyone has different use cases that are most meaningful to them, but a few of the key reasons people love getting a live preview of their working website or web app for every pull request include:
Most of the developers we’ve talked with who use a deploy preview workflow don’t ever want to go back to working without them.
Sure, when you put it like that, deploy previews sound great — but how do automatic branch deployments actually work?
Both Netlify and Tugboat link to your git repository at your git provider, but Netlify only supports GitHub or GitLab; Tugboat supports GitHub, GitLab, Bitbucket, or even a git repo hosted elsewhere. Both services connect to your git provider using OAuth2 to get a client token to secure your sessions.
From here, the process is slightly different. Netlify has a UI where users can select which branches they’d like to build deploy previews against, and you can add an optional netlify.toml in the root of your Git repository to override your normal site build scripts. In Tugboat, this process is managed with a Tugboat-specific config.yml that lives in your git repository.
For new users, the Netlify UI can be a bit difficult to navigate when configuring more complex build pipelines, as you must visit several different screens to manage all the settings you might want to configure. However, the documentation is decent; if you follow enough pages, you should be able to get things running. From the Tugboat side, very little is done in the UI; most of the configuration comes directly from the config.yml, so if you’re more comfortable with infrastructure-as-code, Tugboat’s minimal UI is a bonus.
On the Tugboat side, things you might configure in the UI include things like: Using Repository Settings to:
With these configurations made, both services watch for pull or merge requests and build live, working versions of your website.
Both services can automatically build site previews when you make a new pull request; however, only Tugboat can delete those deploys automatically when the PR is merged. Folks have been requesting the option to delete Netlify deploy previews from as far back as 2018, but at the time of this writing, Netlify does not offer that endpoint via their deploy API and doesn’t offer that functionality in the web UI.
If you want to build branches or tags in Tugboat, you can do that manually anytime — from the Tugboat website UI, or right from your terminal using the Tugboat CLI. Netlify also offers a CLI where you can trigger builds, but building branches in Netlify requires you to first set up deploys for that branch. By contrast, Tugboat can build any branch in a repo as long as it contains a Tugboat config, versus the Netlify workflow which requires you to set up deploys, first. This makes Tugboat very user-friendly when it comes to using a feature-branch-based workflow.
Unlike Tugboat, Netlify does not appear to offer the option to build deploys from tags.
Once deploy previews are built, both Netlify and Tugboat post a comment via the linked git account to a URL where viewers can visit the live preview. Viewers of that URL don’t need to have git access, or access to Netlify or Tugboat accounts, making it easy to share work in progress with anyone.
In Netlify, your deploy preview is part of your Netlify hosting account. You’re locked in with Netlify if you want this functionality, and your website is hosted on Netlify’s hardware.
With Tugboat, you’re not getting a host for your production website; you’re getting a tool that sits somewhere in your deploy workflow; after local development, but before pushing to production. Depending on which type of Tugboat account you use, your Tugboat deploy previews can live on shared hardware if you’re on our Free through Pro tiers, on dedicated hardware if you’re an enterprise customer, or on-premise behind your firewall on your own hardware if you’re using Tugboat on-premise. Our shared and dedicated hardware Tugboat instances are hosted on Linode, and come with Linode’s solid reputation for security and performance.
Tugboat Previews are not intended to replace a dedicated production-level web host. You can use whatever host you prefer for your production-level website; we have customers on AWS, IBM Cloud, Pantheon, Acquia, and many more.
On the surface, the services sound similar. Both Netlify and Tugboat can build working versions of your website to share with people via URL. Netlify provides this service to people who use its platform, while Tugboat is hosting-agnostic, so you can use Tugboat no matter where you host your website or web app.
But Tugboat was built by developers, for developers. It includes a few extra development tools that might be useful beyond just building a live preview of your site. With Tugboat, you can:
These features are in addition to the CLI tools and API that both Tugboat and Netlify offer.
Deploy previews are great, but they can still become a time sink if you’re working with large files, large databases, or complex builds. Waiting for your deploy preview to build is time lost, especially if you switch to another task while it’s building and then have to do another context switch back to troubleshoot build issues. This is where Tugboat really shines; building deploy previews fast.
Tugboat offers a feature that Netlify deploy previews don’t provide: the Base Preview. The idea behind a Base Preview is that you can do all the time-consuming stuff in a deploy preview that you only have to build once. You can set Tugboat to automatically update it at a convenient time, like overnight, to make sure you’re always working with the most recent data and code in your Base Preview.
After you set a Base Preview, subsequent Preview builds can start from that Base Preview, and only have to build the things that are new in a given PR or feature branch. Practically speaking, this means lightning-fast preview builds instead of starting the deploy preview from scratch every time. This can save minutes; sometimes 30 minutes or more if you’ve got a large build. If you’re doing several builds in a row to test or debug some functionality, that time can really add up. Take a look at Tugboat’s guide to Optimize Preview Builds for more info about how these things are implemented in a Tugboat deploy preview.
If you’ve been hearing the hype about deploy previews and have been wondering if it can make a difference in your workflow, give Tugboat a try. We offer a free starter tier that’s enough to build multiple Previews of simple web apps or static site generator websites, and a variety of tiers available if you want to go beyond proof-of-concept and build larger or more resource-intensive deploys.
Tell us about your project, schedule a demo, or consult with a Tugboat Technical Account Executive.