Simplified screenshot of deploy previews on the Tugboat dashboard

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.

Why all the hype about deploy previews?

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:

  • The ability to test new features and implementation before pushing them to a development or production branch.
  • Getting a live preview URL to share work with stakeholders and site users and get feedback.
  • Easier and faster collaboration between front-end developers and designers to make sure the site looks great.
  • Testing new infrastructure configurations (such as version upgrades or new services) without impacting the live site. Ever wanted to try out putting your application behind Varnish? Or prototype adding a search server like Solr or Elasticsearch?
  • Seeing what the site actually looks like, off your local development environment, and getting confidence about what you’re actually rolling out to production — before it goes live. “It worked on my local!” becomes a relic of the past.

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.

How do automatic branch deployments work?

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:

  • Set the git integration to automatically build deploys when there’s a new PR
  • Have Tugboat automatically update the deploy environment when you push new changes to the pull request
  • Set up environment variables to protect sensitive data
  • Automatically update environments at a specific time, such as overnight, to pull in the latest DB, image assets, or other large files so you’re always working with the latest production-like data
  • Automatically delete Tugboat Previews when pull requests are merged

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.

Where does your website live?

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 Premium 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.

Beyond Netlify Deploy Previews: a developer-focused experience

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:

  • View output logs from the preview or individual services within the Preview to more easily troubleshoot issues; the Netlify Deploy log doesn’t break out into services, so it can be more difficult to spot where things went wrong, and you can’t dive deeper into a Netlify deploy build failure.
  • Use your own private Docker images or Docker registry with Tugboat. At the time of this writing, Netlify is just starting to offer different build images as a BETA feature, but this functionality is still restricted to Netlify’s build images, while Tugboat lets you bring your own Docker image from DockerHub or a private registry.
  • Shell directly into the Tugboat preview to test things “locally” within the deploy preview. (Pro tip: this is a great way to get troubleshooting help or do code reviews without requiring someone else to have a local development environment set up.)
  • Work with large files or sites; Netlify’s docs point out that files over 10MB in size may fail to upload to the system, causing the entire deploy to fail, but Tugboat is perfectly happy to pull in multi-GB files such as large databases or image assets.

These features are in addition to the CLI tools and API that both Tugboat and Netlify offer.

Speed up deploy preview builds with Tugboat’s Base Previews

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.

Try out Tugboat Previews in your workflow

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.