Netlify extensions are installable add-ons that wire third-party services or extra platform features into a project from a directory in the dashboard, replacing what used to be a manual configuration and credential exercise.
The pitch is one click, and for the common cases it genuinely is. The thing worth understanding before leaning on them is what each extension is actually doing on your behalf, because that determines how much of your setup is portable and how much is a dashboard toggle nobody has documented.
Table of contents
- What an extension actually is
- Build steps, which are the safest to adopt
- Service integrations and the questions to ask
- The pattern worth watching
- A reasonable policy
- How this fits the rest of the stack
- FAQ
What an extension actually is
Under the branding, extensions do one or more of three things.
- Connect a third-party service. Provision or link an external product - a database, a CMS, a feature-flag service, a security layer - and inject the credentials into your project’s environment so your code can use them without you copying keys around.
- Add a build step. Run something during the build: generate a sitemap, check for broken links, run a Lighthouse audit, submit source maps to an error tracker. These were previously called build plugins and are the oldest part of the category.
- Enable a platform capability. Turn on a feature of the hosting platform itself rather than integrating anything external.
The first type is the most consequential, because it creates a relationship between your project and another vendor that is managed through a third party’s dashboard. That is convenient and it is one more place where an important piece of your configuration lives.
Build steps, which are the safest to adopt
Extensions that run during the build are the least entangling, because a build step is fundamentally just a command.
The genuinely useful ones catch problems before they reach production: a broken-link check across the generated output, a bundle-size budget that fails the build when someone imports a large library, an accessibility scan, sitemap generation, and source map upload for readable production stack traces.
The important habit is knowing what each one would be as a plain command, because that is what makes it portable. A link checker installed as an extension and a link checker run as a script in your build command do the same job; only one of them survives a change of host. Where an extension is a convenience wrapper around a CLI tool, consider running the CLI tool directly and keeping the configuration in your repository.
Where the extension does something genuinely platform-specific - reading deploy metadata, interacting with the CDN, hooking into the deploy lifecycle - the wrapper is the point and there is no portable equivalent.
Service integrations and the questions to ask
- Who owns the account? Some integrations provision a resource under the platform’s arrangement with the vendor rather than under an account you control. Find out which, because it determines whether you can take the resource with you.
- Where does the billing go? Consolidated onto your hosting invoice, or a separate relationship with the other vendor? Both are fine; not knowing is not.
- What credentials were injected, and where? The convenience is that keys appear in your environment automatically. The cost is that six months later nobody knows where a variable came from. Write it down.
- Is the underlying service standard? A managed Postgres provisioned through an integration is portable, because Postgres is Postgres and a dump restores anywhere. A proprietary datastore with a bespoke API is not.
- What happens if you uninstall it? Does the external resource persist, or does removing the integration remove the thing?
The pattern worth watching
Individually, every extension is a small convenience with a clear benefit. Collectively, they can become the place where a meaningful amount of your architecture is defined - and unlike code, none of it is in your repository, reviewed, or visible in a diff.
The test is straightforward and slightly uncomfortable: if you had to recreate this project on different infrastructure, how much of what makes it work is in the repository, and how much is toggles somebody set in a dashboard eighteen months ago?
The mitigation is not avoidance. It is documentation and preference. Keep a list of installed extensions and what each provides. Prefer configuration in files in the repository over configuration in a dashboard where the two are equivalent. And keep the genuinely load-bearing pieces - the database above all - on standard technology with a portable format, so that whatever else moves, the data does not have to be rebuilt.
A reasonable policy
Adopt build-step extensions freely; they are cheap to replace and they catch real problems. Note what each one would be as a command.
Adopt service integrations deliberately, checking account ownership, billing, and whether the underlying service is standard. Prefer standard databases over proprietary ones every time, since that single preference does more for portability than every other decision combined.
And keep a written record of what is installed and why. This costs ten minutes and it is the difference between a migration and an archaeology project.
How this fits the rest of the stack
The pieces that extensions most often add - a database, storage, a build check - are also the pieces worth being able to price and move on their own terms. The RunxBuild hosting calculator shows the static site, the service, the database, the storage, and the bandwidth as separate line items so nothing is hidden behind a toggle. RunxBuild static sites build from a repository with custom domains, headers, redirects, rewrites, and SPA fallback and include 120GB of bandwidth, with managed MySQL and Postgres available alongside as standard, portable databases.
Useful related references:
- Authorized Domains: The Production Checklist Most Apps Forget
- A Private Network for Cloud Apps: The Three Meanings, the Three Use Cases, and the One Most Teams Skip
- Port Forwarding vs Port Triggering: The Real Difference, the Security Trade-Off, and Why Cloud Apps Need Neither
- Services on RunxBuild
FAQ
What are Netlify extensions?
Installable add-ons in the dashboard that do one of three things: connect a third-party service and inject its credentials into your project, add a step that runs during the build, or enable a platform capability. They replaced what was previously manual configuration and key copying.
What is the difference between an extension and a build plugin?
Build plugins were the earlier name for extensions that run during the build - sitemap generation, link checking, source map upload. The extension category is broader and also covers service integrations and platform feature toggles.
Are build extensions portable to other hosts?
It depends what they wrap. An extension that runs a CLI tool has a portable equivalent - the same command in your build script, with configuration in your repository. An extension that reads deploy metadata or hooks into the platform’s deploy lifecycle does not.
What should I check before installing a service integration?
Who owns the provisioned account, where the billing goes, which credentials were injected into your environment and from where, whether the underlying service is standard technology or proprietary, and whether uninstalling the integration removes the external resource.
How do I avoid my configuration ending up in a dashboard?
Ask whether you could recreate the project elsewhere from the repository alone. Prefer configuration in files over dashboard toggles where they are equivalent, keep a written list of installed extensions and what each provides, and keep databases on standard technology with portable dumps.