10 Netlify features to surprise and delight
During my first days as a Netlify employee, I learned about some features that surprised me. The response to my tweet announcing my new role was interesting, too. I received lots of kind words of congratulations along with questions about features I assumed were well known or understood. To be fair, Remy’s question was a nice easy one to get me started in my role in developer relations:
I got you, Remy! Think, “Net” and “Simplify”.
Now say it with me: net — li — fy.
At first glance, you’d be forgiven for thinking that Netlify was a static web hosting solution. It is, but it goes so much further. The recent work to re-platform Smashing Magazine onto the JAMstack hosted on Netlify is showing the incredible potential of this approach.
So here is a quick list of some of the Netlify features you might not know about. All of these are available no matter which payment tier you’re on. Yes, even the free tier.
But first, a word on the simplest way to start
It is incredibly simple to get started with Netlify. And you don’t need to know about all of the powerful features under the hood to start benefiting from them.
There is also a tool which you can use to deploy directly from your command line, but I’ll let you read about that over in the excellent docs, otherwise it might look like I’m cheating by trying to slip in a couple of extra things ahead of my list without tipping over the 10 item limit.
I was. You caught me. Ok, onto the list proper.
1. Atomic deploys with instant publishing and rollbacks
This one will feel like a luxury to anybody who has worked for a traditional client on a large web development project, which included things like “deployment”, “go live” or “cutover” in the project plan.
Every successful build on Netlify results in a newly-deployed instance of your site. Publishing to Netlify’s CDN edge nodes and things like cache invalidation happen automatically and as close to instantly as I’d care to measure.
Deploys are immutable. That is to say that each deployment results in a version of the site which never changes. Subsequent updates create new instances of the site to replace previous versions (which are quietly thanked for their service and put into retirement, but not destroyed). This means that you can rollback to any previous build at any time with just a click of a button in the admin console, or via the API.
(Everything you can do via the admin console is also possible via the API, by the way. (Check out the API docs to get a sense of how much you can do.) That isn’t one of my 10. It’s just a little bonus nugget for you!)
2. Notifications and permalinks
I’m at it again. I’m trying to squeeze more than one detail into a single item on this list. Whatever. You might as well get used to it.
Netlify allows you to set up notifications based on different deployment events. You can define who gets notifications for events like the start of a deployment, or when a deployment succeeds, fails, is locked or unlocked.
You can configure notifications to go to email addresses or to a Slack channel (which I love; all my projects have a CI slack channel). You can even have these notifications trigger a webhook or add messages to Git commits or comments to pull requests.
What makes these notifications even more helpful is that they include a permalink to the deploy in question. I mentioned earlier that all deployments are immutable and live forever. That means that each one can have it’s own URL which you can access to see that deployment.
Having permalinks for every deployment is huge. It immediately unlocks the ability to share the state of any version of your build with the testing team, the client, anyone. “What did the site look like at v3.2.14? Ah here it is.”
And this instant access is delivered right to you from each notification.
3. Branch deploys and subdomains
It is really handy to be able to deploy branches besides master. Building your new features in feature branches and then testing and reviewing them in your real hosting environment is incredibly powerful.
Netlify gives you some control over how you deploy. You can choose whether to deploy just your production branch, all branches, or some named branches.
Once deployed, each branch will be available on a subdomain with a name derived from the name of the branch it came from. It looks like this:
With Netlify’s DNS management, you can assign your own subdomains to branches, too. You get total control over how different branches drive the content on different subdomains of your site.
4. A/B testing, multi-variant testing or split testing
People refer to A/B testing by a number of different terms, but Netlify calls it “split testing” because it does just that: splits the traffic to your site between any branches you specify.
You can split your traffic across as many branches as you like, defining what percentage of traffic should go where.
This feature blows me away. It makes real A/B, or multi-variant testing trivially easy to achieve. If you are taking advantage of the branch deploys already, there is very little left to do.
More than that, if the performance of the variants we are testing differ to what is “live”, then how can we ever get a true like-for-like comparison of how the options perform? The tests are skewed.
Netlify’s approach serves each variant directly from its custom-built CDN. All of the traffic-shaping, variant weighting, user consistency assurance, and other clever stuff happens right there on the CDN — at the edge, as close to the user as possible.
Every variant is served and rendered “as production”. Amazing.
5. Contextual build commands
Not only can you deploy different branches, you can also customise the content and environments in your deployments to suit different contexts such as staging, testing and production.
It used to be that providing different environments for your project could be complicated. Netlify makes this simpler than I’ve ever seen it before. You can create
testing.your-project.com or whatever else you need alongside your
www.your-project.com with little more than some configuration. And they all receive identical environments which is such an important aspect of a robust development and release strategy.
You may want to run some slightly different build commands depending on the environment you are deploying to, or to build a feature which is not yet in production. You can do that by configuring different build contexts.
This lets you do things like build for production with
gulp build:prod and for a feature branch build with gulp
This is configured by a config file that you can keep in the root of project to access all sorts of options in your Netlify builds:
You can find more details about deploy contexts in the docs.
6. SSL Management and free SSL from Let’s Encrypt
Although it might not be immediately obvious, it is actually very important to serve websites over HTTPS rather than just HTTP, even if they are served as static sites.
Convinced and now shopping for a digital cert? Fear not. This can be made simpler than you might think.
Most people can get what they need from Managed SSL thanks to the free certificates provided by Let’s Encrypt. Set up takes one click (ok, it might be a total of three clicks, but it took me less than a minute). Even better, the certificates renew automatically so you don’t need to tend to this each year.
7. Running tests with Netlify’s continuous integration
One of the things that gives Netlify its power is that in addition to a purpose-built CDN for hosting your sites, it also provides a containerized environment to run your builds. That means that whatever build you run in your local build environment or on a continuous integration server could actually run directly in Netlify.
If your build includes tests, Netlify will execute these for you and yield either a successful build or a failure, notifying you of the results.
Replace my CI infrastructure, my hosting infrastructure and my deployment pipeline with a single service? Yes please.
8. Form handling
If your site needs to host forms, you might have decided in the past that a static site just won’t work. However, Netlify has an easy solution.
If you need to have a form on your site which accepts content submitted by your visitors, Netlify can host that for you. By simply adding an attribute to the HTML of your form, Netlify will generate a suitable end point for the form and make all of the data posted available to you via the admin UI and an API.
With the content accessible via an API, you can access that content during your build and use it in the generation of your site. With a little imagination this unlocks all sorts of interesting possibilities.
9. Redirects, rewrites and proxying
Leave no URL behind! By including a
_redirects file in your deployed directory you can gain access to rich configuration options for redirects and rewrites. These happen at the CDN edge nodes which make them incredibly fast and efficient.
You also have the ability to specify the HTTP response code in the _redirects file making a few other things like custom 404s and even proxying to other resources possible.
You want splats, placeholders, query parameters and more? Take a look at the redirects documentation.
10. Custom header control
This is one for anybody who has been hosting their site on Github Pages and chasing that perfect Lighthouse or Page Speed Insights score. You’ve done everything right, but you need control over your HTTP caching headers to get that last bit of performance optimisation you’re missing… sadly, you don’t have that power.
Now you do.
For this Netlify uses a similar approach to how you manage redirects (above). By including a
_headers file in your deployed directory you gain control over the HTTP headers for all and any of resources in your site.
And you can do more than just control your cache headers. The ability to configure your headers via the
_headers file allows you to do things such as define your Content Security Policy (CSP) your X-Frame-Options, and all kinds of other important things to help control security of your site.
Having this kind of control at such a granular level is often far more complex than this. It feels to me that this feature bring sensible security control into reach for so many more developers.
That’s 10, but there’s so much more
I could have mentioned so many other things. But you don’t want a list that goes on for ever.
The deeper I dig, the more power and control I discover. It’s important to retain a simple, low-friction way for developers to get their JAMstack sites online, but with this ecosystem growing all the time, the ceiling for what is possible is getting higher and higher.
It’s worth keeping an eye on Netlify. There are some exciting upcoming features being tested by enthusiastic Alpha testers right now.