There is no system-extension profile
The current release does not ship a system extension, so there is nothing to pre-approve
and no profile for one in these kits.
Trust Center
Deploy it to the fleet, lock the settings, and know what you cannot lock.
Bolt ships enterprise deployment kits for both halves of the product: the desktop app and the browser extension. Settings can be pushed from the management platform you already run and pinned so users cannot change them, and on Chromium the extension genuinely cannot be removed or disabled. This page says which parts are enforceable, and which are not.
The browser extension
Force-installed, and no store listing required.
Your organization can host the package itself; the Chrome Web Store listing is there for people who install it on their own. Administrators usually ask about the store first, so here is the answer per browser.
Browser
How it is deployed
What to know
Chrome, Edge, Brave
Force-installed by policy from a package your organization hosts on its own internal HTTPS server. Set installation_mode to force_installed and the user cannot remove or disable it, and the browser puts it back if the profile is reset. The kit ships the policy JSON, the Windows registry form and the update manifest, with the extension id already pinned.
The extension is on the Chrome Web Store, and companies can still force-install it by policy. To host your own copy, you pack and sign the .crx yourself with Chrome's own --pack-extension; we ship the extension as a zip, not as a signed .crx.
Firefox
Force-installed through the policies.json mechanism from your own internal URL, with admin settings delivered through the same key names as Chrome.
Mozilla must sign the package, which is free and produces no public listing. Firefox release builds refuse unsigned add-ons and enterprise policy cannot override that.
Safari
Ships inside the signed and notarised Bolt desktop app as a Safari Web Extension, built from the same package as the Chrome one. Installing the app installs it.
No App Store submission. Admin policy reaches it through a native bridge, because Safari's managed-storage channel is unreliable and would otherwise drop the extension back to defaults without saying so.
The desktop app
Policy from the platform you already run.
Platform
How policy is delivered
On preventing removal
macOS
A configuration profile payload targeting the app's bundle id, deployable through Jamf Pro, Intune, Kandji or any MDM that takes a custom profile. The template is in the kits below.
Deploy the profile as non-removable on a supervised device and the locked settings stand. Restricting removal of the app itself needs Automated Device Enrolment.
Windows
Group Policy templates (ADMX and ADML) so the settings appear in the Group Policy Editor and can be ingested by Intune.
A required Intune app reinstalls after removal, the entry can be hidden from Programs and Features, and AppLocker or WDAC stops a substituted binary running.
The deployment kits
Download the templates. No form, no email.
These are the same files we deploy from. They are templates: each one says at the top which placeholders to replace before it goes to a device.
Desktop app on macOS
Upload each profile to your MDM as a custom profile. Replace the placeholders named at the top of each file first.
File
What it is for
Locks Bolt's settings from your MDM: data protection level, the sites and apps it covers, vault rules and in-app updates.
Pre-approves the macOS privacy permissions Bolt needs, so users without admin rights are not asked to grant them by hand.
Lets the Bolt browser extension reach the desktop app on a managed Chrome, Edge, Brave, Chromium or Vivaldi that blocks native messaging by default.
Desktop app on Windows
Keep the two files together: the language file must sit in an en-US folder next to the template.
File
What it is for
Group Policy template. Adds a Bolt Desktop category to the Group Policy Editor, and Intune can ingest the same file.
The English names and help text for every setting in the template.
Browser extension
Replace INTERNAL-HOST and the example-corp addresses with your own before deploying.
File
What it is for
Chrome, Edge and Brave policy that force-installs the extension from a host you run.
Firefox policies.json that force-installs the signed add-on and delivers its settings.
The admin settings the extension reads, as an example to adapt.
Windows registry file that sets the same Chrome policy, for scripted rollouts without a Group Policy template.
Step-by-step guides
One page per job. Each explains what its template does, how to deploy it, and how to verify the result on a device.
Guide
What it covers
What each entry in bolt-pppc.mobileconfig pre-approves and why, what a profile cannot pre-grant, how to deploy it, and how to check the grants landed. Also covers the native-messaging profile.
Every key bolt-desktop.mobileconfig can set, how each one merges with other sources, and the steps to deploy and verify it.
Where Bolt reads policy in the registry, how to load the ADMX and ADML template into Group Policy or Intune, and how to verify it.
Binary allowlisting
Santa rules, ready to import.
If your Macs run Santa in lockdown mode, nothing unknown starts. These are the rules that let Bolt start, at the granularity you choose, with the identity to check them against.
Identity
Value
Team ID
4VSW7NBZ2SSigning authority
Developer ID Application: Sparcle Inc. (4VSW7NBZ2S)Main bundle ID
app.sparcle.bolt.enterpriseNotarization
Stapled to the app, so it verifies offline.Rule set
File
What you are approving
Signing ID
Recommended. One rule per Bolt binary, 132 in all, including the embedded database. It survives updates and cannot widen to a different Sparcle product.
Team ID
One rule you never touch again. It is also a standing approval of anything else Sparcle signs in future, so pick it knowing that.
CDHash or SHA-256
Exact per-release hashes for fleets that approve each release. They are invalid at the next release, so they ship with each release instead of living on this page: one file per Mac architecture, named bolt-<version>-allowlist-<arch>.zip, measured from that release's own installer.
sudo santactl rule --import bolt-signingid.jsoncodesign -dv --verbose=4 /Applications/Bolt.appWhy the database needs its own rules
Bolt keeps its data in a local database that ships as an archive inside the app and is
unpacked on first run. Each of those binaries has its own signing identifier, so a rule
set that names only the app allows Bolt and blocks its database. The signing ID file
names every one of them. They are signed by the same Team ID as the app.
Checked against every binary, not yet on a live Santa fleet
The rules were compared with the code signature of every binary in the 0.1.170 Apple
silicon installer, including the database files, and each one matched a rule. We have
not yet run them on a fleet in lockdown mode. Start in monitor mode, read what Santa
logs for Bolt, and tell us about anything it would have blocked.
How settings are pinned
Two tiers, and the difference is the whole rollout decision.
Tier
What it is
When to use it
Forced
Read from the management-owned location: the MDM's managed preferences on macOS, the Group Policy tree on Windows. The setting is locked in the app: it renders as managed by your organization and the control is disabled.
Use this for anything your policy requires.
Device default
Read from the administrator-writable location. It gives the user a starting value they can still change.
Use this for sensible defaults you do not need to enforce.
The user's own settings are never read as policy
On macOS a user can write their own preference file, and on Windows a user can write
their own registry hive, both without any privilege at all. Because a forced setting
wins outright, reading either would let any user hand themselves policy, including
switching the data-protection guard off. Neither is read, and a test pins it.
A lock means the platform said so
The app asks the operating system whether a setting is forced rather than inferring it
from the value being present. A central server never claims to have locked something on
a laptop it has not touched, because that would show a lock badge for an enforcement
that does not exist.
What cannot be prevented
No application can stop its own removal, including ours.
How close you get is a property of your management platform, not of the software, and we would rather you plan around the real answer.
An unmanaged administrator on their own machine can defeat any on-device control
This is true of every product in this category. It is why the browser extension and the
network layer exist alongside the app rather than instead of it, and why the coverage
signal in the admin console matters: the useful question is not whether the control can
be defeated, it is whether you find out.
Fleet coverage reporting is deliberately conservative
The admin console reports how many people have actually produced governance events. It
does not claim a per-device attestation it cannot make, and it undercounts rather than
overcounts: a device that is enrolled but idle does not appear. A number that flatters
the rollout would be worse than a number that is short.
Stuck on a rollout? Tell us your management platform.
Jamf, Intune, Kandji, Group Policy, Workspace, or something else. The templates are above. If one does not fit your setup, we will work through it with you.