How to Make an Installer for Your Audio Plugin (Windows and macOS)

By the end of this guide you will know how to make an installer for your audio plugin that puts your compiled .vst3, .component, or .clap into the right folders on Windows and macOS, and gets past the security checks that block unsigned software. If you have been zipping up a folder and telling users to drag files around, this is the upgrade that makes you look like a real product.

What an installer actually does

Strip away the branding and the progress bars, and a plugin installer does one boring, essential thing: it copies your plugin bundle into the folders your users' DAWs scan at startup.

A DAW does not hunt across the whole disk for plugins. It looks in a fixed set of known directories. If your .vst3 is not in one of those directories, the DAW will never find it, no matter how good the plugin is. An installer's whole job is to place the files where the scan happens, and (ideally) to clean them up on uninstall.

That is it. Everything else (a nice UI, a license agreement page, an uninstaller entry) is polish on top of that copy operation.

Where plugins actually go

Here are the standard scan locations. Get these exactly right, because a plugin in the wrong folder is a plugin that does not exist as far as the host is concerned.

Windows

• VST3: C:\Program Files\Common Files\VST3
• CLAP: C:\Program Files\Common Files\CLAP

These are the system-wide locations, and they are where virtually every Windows DAW looks by default. Installing here requires administrator rights because Program Files is protected.

macOS

On macOS, formats live under /Library/Audio/Plug-Ins:

• VST3: /Library/Audio/Plug-Ins/VST3
• Audio Unit (AU) components: /Library/Audio/Plug-Ins/Components
• CLAP: /Library/Audio/Plug-Ins/CLAP

Those are the system-wide paths, and they need administrator rights to write to. There is also a per-user equivalent under the user's home folder that does not need admin:

• ~/Library/Audio/Plug-Ins/VST3
• ~/Library/Audio/Plug-Ins/Components
• ~/Library/Audio/Plug-Ins/CLAP

Most commercial installers write to the system-wide /Library paths so the plugin is available to every user account on the machine. The user-level paths are handy for testing or for users who cannot get admin access. Note that AU is a macOS-only format, so you will only deal with the Components folder on the Mac side.

One macOS detail worth knowing: a .vst3, .component, or .clap is not a single file, it is a bundle, which is really a folder that Finder displays as one item. Your installer needs to copy the whole bundle directory, not a single file inside it.

Building the Windows installer

The two standard, free tools are Inno Setup and NSIS. Both are mature and widely used for audio plugins.

• Inno Setup uses a readable .iss script format that is easy to learn. It is the friendlier starting point for most people.
• NSIS is more scriptable and lower level. It gives you more control at the cost of a steeper syntax.

For a typical plugin, Inno Setup does everything you need. Here is a minimal script that copies a VST3 bundle into the Common Files VST3 folder:

[Setup]
AppName=My Plugin
AppVersion=1.0.0
DefaultDirName={commoncf}\VST3
DisableDirPage=yes
PrivilegesRequired=admin
OutputBaseFilename=MyPlugin-Installer

[Files]
Source: "build\MyPlugin.vst3\*"; DestDir: "{commoncf}\VST3\MyPlugin.vst3"; Flags: recursesubdirs createallsubdirs ignoreversion

[UninstallDelete]
Type: filesandordirs; Name: "{commoncf}\VST3\MyPlugin.vst3"

A few notes on what is happening:

• {commoncf} is Inno Setup's built-in constant for the Common Files folder (C:\Program Files\Common Files on a standard install), so {commoncf}\VST3 resolves to the correct VST3 directory. Using the constant is safer than hardcoding the path, because it stays correct on non-English Windows installs and on systems where the drive is not C:.
• On Windows a .vst3 is usually a folder bundle too, so the Source uses a wildcard with recursesubdirs to copy the whole thing. If you are shipping a single-file .vst3, point Source at the file directly.
• PrivilegesRequired=admin prompts for elevation, which you need to write into Program Files.
• The [UninstallDelete] section makes sure the plugin folder is removed cleanly when the user uninstalls.

To add CLAP, you would add another [Files] line targeting {commoncf}\CLAP. The structure is identical.

Building the macOS installer

On macOS the standard installer format is the .pkg. A .pkg is an archive plus a small set of instructions that the macOS Installer app reads. It can place files into the system plugin folders, run scripts, and show a license agreement, all through the familiar Apple installer window.

You have two main routes to build one.

Command line: pkgbuild and productbuild

Apple ships two command-line tools with the Xcode command line tools:

• pkgbuild takes a folder of files and turns it into a component package, recording where each file should be installed on the target machine. This is where you say "put this .component into /Library/Audio/Plug-Ins/Components."
• productbuild wraps one or more component packages into a final distribution .pkg, and lets you add a welcome screen, license text, and installer UI.

The typical flow is: build your plugin, stage it into a directory that mirrors the install layout, run pkgbuild to make the component package, then run productbuild to produce the distributable installer. This pairs well with a build script or CI because it is fully scriptable.

The Packages app

If you would rather not hand-write installer scripts, the free Packages app gives you a graphical way to define which files go where, add a license, and build the .pkg. It is a popular choice for plugin developers who want a visual tool, and it produces the same kind of installer the command-line tools do.

Either route gets you to the same place: a .pkg that drops your bundles into the system plugin folders.

Code signing and notarization

This is the step people skip and then get bitten by. Modern Windows and macOS both treat unsigned installers as suspicious, and macOS goes further and will refuse to run them at all in the default configuration.

Windows code signing

On Windows, you sign your installer (and ideally the plugin binaries) with a code signing certificate from a recognized certificate authority. Without a signature, users get a SmartScreen warning that says the publisher is unknown, and many will bail out right there. With a valid signature, your name shows up as the verified publisher and the warning goes away (standard certificates still build reputation over time; EV certificates tend to skip that warming-up period).

You sign using a signing tool with your certificate, and the signature is embedded in the installer executable. This does not change what the installer does, it just proves the file came from you and has not been tampered with.

macOS signing and notarization

macOS is stricter. Gatekeeper is the system that decides whether downloaded software is allowed to run, and by default it blocks anything that is not both signed with a Developer ID certificate and notarized by Apple. If you hand a user an unsigned or un-notarized .pkg, they will hit a wall that says the package cannot be opened or is from an unidentified developer, and getting past it requires digging through system settings that most users will not attempt.

You need a paid Apple Developer account for this. The high-level flow is:

1. Sign your plugin bundles and your installer with your Developer ID certificate.
2. Notarize: submit the signed installer to Apple's notarization service. Apple runs an automated malware and policy check and, if it passes, issues a notarization ticket. This is a network round trip that usually takes a few minutes.
3. Staple: attach the notarization ticket to your installer so Gatekeeper can verify it even when the user is offline.

Apple provides command-line tooling to submit for notarization and to staple the ticket. I am not going to spell out exact flags here because they change between tool versions, so check Apple's current developer documentation for the precise commands. The three-step shape (sign, notarize, staple) is the part that stays stable and is what you should design your build around.

The practical takeaway: budget time for signing and notarization from the start. It is not optional for a product you expect strangers to install, and it is the part most likely to surprise you the first time.

Always test on a clean machine

Your development machine is the worst place to test an installer. It already has your plugin's dependencies, old copies of the bundle, and your signing setup. An installer that "works" on your machine can fail instantly on a fresh one.

Test on a clean environment: a spare computer, a fresh user account, or (easiest) a virtual machine with a stock OS install and nothing else. Run the installer exactly as a customer would, from download to first launch in a DAW, and confirm:

• The plugin lands in the correct folder.
• A real DAW scans and loads it.
• On macOS, Gatekeeper lets the installer run without warnings (this is where un-notarized builds get caught).
• The uninstaller removes what it added.

A VM you can snapshot and reset is worth the setup time, because you can test the very first-run experience over and over.

If you would rather not do all this

Building and maintaining installers for two operating systems, keeping signing certificates current, and re-notarizing on every macOS update is real ongoing work that has nothing to do with your actual DSP. If you would rather skip it, distributing through a launcher or store that installs and updates the plugin for the user (which is what Woopo does) means the copy-to-the-right-folder step, the signing, and the updates are handled for you, and you just ship the build. Worth considering if installer plumbing is not how you want to spend your time.

Wrap-up

An installer is fundamentally a file-copy operation into a handful of well-known folders. Get the paths right (Common Files\VST3 and Common Files\CLAP on Windows, /Library/Audio/Plug-Ins on macOS), pick a tool (Inno Setup or NSIS for Windows, pkgbuild and productbuild or the Packages app for macOS), sign everything, notarize on macOS, and test on a clean machine before you ship. Do those five things and your plugin installs like a professional product instead of a zip file full of instructions.

Sell your plugin on Woopo →