Publishing
Flare installs plugins only from the store. Anyone with a Flare account can publish there, and anyone can install in one click. Users see every scope a plugin asks for before it installs.
Flare doesn't install plugins from a file, a folder or npm, because the store is what makes a plugin safe to install. Everything in it passes the automatic checks, and anything that can read or change your data, or reach the network, is reviewed by a person at Flare before it goes live. To run a plugin you're building, use Developer mode, described in The dev loop. It runs only on your computer.
The store
Published plugins are listed at flare.tools/plugins and in the app under Settings, Plugins, Discover. Each plugin gets a page with its description, README, scopes, versions and download count.
Downloads count once per user or address, per plugin, per day. The number reflects how many people use a plugin, not how often it updates.
Installing from the store
Users install a store plugin in one of three ways:
- Discover, in Settings, Plugins: search, filter by kind, and press Install on the plugin's row or in its detail beside the list.
- Install in Flare on the plugin's page at flare.tools/plugins.
- A link to
flare://plugins/install/<id>, anywhere. Add?version=1.2.0to install that version.
[Install in Flare](flare://plugins/install/flare.stripe)Flare downloads the package through the store, checks it against the hash the store sent with it, and checks that it's the plugin the link named. Then it shows the usual install dialog, with every scope. Nothing installs until the user allows it. If the plugin is already installed at that version, the link opens it in Settings, Plugins.
Publish a plugin
You need a Flare account to publish, because tokens are made in the app while you're signed in. Flare is taking new accounts through its waitlist for now.
1. Create a publishing token
In Flare, open Settings, Plugins, Developer and choose New token. Name it for where it will be used, such as a laptop or a CI job. Copy it now: Flare shows it once and keeps only a hash. Afterwards you'll see its first few characters, so you can tell tokens apart. Revoke any token that leaks, on the same screen.
A token can publish your plugins and nothing else. It can't make tokens or read your account.
2. Sign in
npx flare-plugin loginPaste the token when asked, or pass it with --token. The CLI checks it with the store and keeps it in your user's config folder, readable only by you. flare-plugin whoami shows which account you're publishing as, and flare-plugin logout removes the token.
In CI, set FLARE_TOKEN instead. It's used before a kept token.
3. Publish
npx flare-plugin publishpublish validates and builds the plugin, packs it like flare-plugin pack, and uploads it. It prints the result: the version, whether it went live or is waiting for review, and every check.
flare-plugin publish
● flare.orders (Orders 1.1.0): the manifest is valid, with 1 widget and 1 row action
● It asks for 2 scopes:
data:read Read the database you have open
data:write Change records in it
A person will review this before it goes live, because it can change data.
● Built dist in 412ms plugin.js 7.9 kB, plugin.css 2.3 kB
● Sending flare.orders 1.1.0 to the store (https://api.flare.tools)
● flare.orders 1.1.0 is waiting for review.
A person reviews it before it goes live, because it can change data.
Flare emails you the decision, with any note from the reviewer.
flare-plugin status shows where it stands at any time, as does Flare: Settings, Plugins, Developer.The first version you publish claims the plugin's id for your account. Later versions must come from the same account, each with a higher version. The store takes plain release versions, such as 1.2.0, with no pre-release tags.
The checks
Every version goes through automatic checks first:
| Check | What it looks at | When it fails |
|---|---|---|
| The package | A safe archive under 10MB, with no links, no absolute paths and nothing outside its own folder. | Error |
| The manifest | Valid for the plugin API Flare has now, as flare-plugin validate checks it. | Error |
| The bundle | dist/plugin.js is present, for a plugin with code. | Error |
| Themes | Each theme's colours meet WCAG contrast. See Themes. | Warning |
| What the code does | Dynamic code (eval, new Function), remote script or style URLs, and very long single lines that suggest hidden code. A sandboxed plugin needs none. | Warning |
An error fails the version, with the message, and nothing is listed. A warning sends the version to a reviewer, even if its scopes wouldn't. Information findings are shown and change nothing.
Run flare-plugin validate and flare-plugin build before you publish, and the first three checks won't surprise you.
Review
After the checks, what a version can do decides where it goes. reviewTier in @flare/plugin makes the same call:
| A version that | Goes |
|---|---|
| Touches no data: adds themes, formats cells on screen or copies text, with no warnings | Live at once, after the checks. |
Can read data (data:read), change it (data:write), reach the network (network:<host>), or got a warning | To a person at Flare, for review. |
Anything that can see your data is reviewed by a person, not only what can change it or send it away. Review happens on Flare's staff dashboard, and nobody reviews a plugin they published themselves. The reviewer sees the manifest, the scopes and any it adds beyond the live version, the check results, the README and every file in the package. They approve the version, with a note if they want to leave one, or turn it down with a note that says why.
Approving puts the version live. Review usually takes a few days. If a reviewer approved the live version, the plugin's page in the store shows Reviewed by Flare.
Hearing about a decision
When a person at Flare decides on your plugin, Flare emails the address of the Flare account you publish with. You get one email for each decision:
- Approved: "Row tools 1.2.0 is live", with a link to its store page and the reviewer's note, if they left one.
- Not approved: "Row tools 1.2.0 was not approved", with the reviewer's note in full and what to do next.
- Removed: "Row tools 1.2.0 was removed from the store", or "Row tools was removed from the store" for the whole plugin, with the reason.
publish already tells you what the automatic checks decide, so there's no email when a version goes live without review or fails a check.
Where your versions stand
Run flare-plugin status in your plugin's folder, or flare-plugin status <id> anywhere, to see every version you've sent, newest first, with the date, any note from Flare and what the checks found. It signs in the same way as publish.
flare-plugin status
● flare.orders (Orders), 1,204 downloads
● 1.2.0 Waiting for review sent 14 September 2026
The checks found nothing.
A person at Flare reviews it before it goes live, usually within a few days. Flare emails you when they decide.
● 1.1.0 Not approved sent 10 September 2026
The reviewer’s note:
Delete rows removes the selected rows without asking first.
Ask before deleting, and say how many rows it will remove.
The checks found nothing.
● 1.0.0 Live sent 2 September 2026
The checks found nothing.Add --json to get the plugin as JSON, for a script that waits on a review. status in the JSON is one of live, in_review, rejected, failed and removed, and if something goes wrong you get { "error": { "code", "message" } } and exit code 1.
The same list is in Flare, under Settings, Plugins, Developer, in My plugins.
| Status | What it means | What to do |
|---|---|---|
| Live | In the store. Users can install it. | Nothing. |
| Waiting for review | Waiting for a person at Flare. | Wait. Flare emails you the decision. |
| Not approved | A reviewer turned it down. Their note says why. | Fix it and publish a newer version. |
| Failed checks | A check found an error. The package wasn't kept. | Fix it and publish again. The same version works. |
| Removed | Flare took it off the store. The reason is with it, and was emailed to you. | Fix it and publish a newer version, unless the whole plugin was removed. |
A version number that wasn't approved can't be sent again. A failed one can. Once a whole plugin is removed, the store takes no new versions of it.
Get through review faster
Ask for as little as you can, and make what you can optional. Say in the README what the plugin sends where, and why. Reviewers read every file you ship, so keep dist/ readable: minified is fine, obfuscated is not.
Update a plugin
- Raise
versioninpackage.json. - Run
flare-plugin publishagain from the same account.
Updates go through the same checks, and review when they need it.
Flare checks store plugins for updates when Settings, Plugins opens and once a day. The Updates tab lists what's newer, with any new scopes it asks for. Update shows the install dialog with only what's new in front of the user. If they allow it, the update installs and the plugin stays on. See What users see.
What gets uploaded
publish packs the plugin before it sends it. To see what it will send without sending anything, run npm run pack. flare-plugin pack validates and builds, then writes <name>-<version>.tgz in the plugin's folder, the same package publish uploads:
flare-plugin pack
● flare.orders (Orders 1.0.0): the manifest is valid, with 1 widget and 1 command
● Built dist in 398ms plugin.js 6.1 kB, plugin.css 2.3 kB
● Packed flare-plugin-orders-1.0.0.tgz 5 files, 4.2 kB
This is what flare-plugin publish uploads to the store.The archive holds package.json, dist/, the README, a licence and changelog if you have them, and the icon the manifest names. Your source files stay on your computer. The format matches npm pack, with every file under package/, and scoped names follow npm: @flare/orders at 1.0.0 becomes flare-orders-1.0.0.tgz.
What Flare checks on install
When a plugin installs from the store, Flare checks it again before showing the user anything:
- the download matches the integrity hash the store sent with it, and is the plugin and version asked for;
- the package has a
name, aversionand a validflaremanifest, and each problem is reported with its location; - the manifest's
apirange matches this version of Flare; - the archive has no links, no absolute paths and nothing outside its own folder.
A plugin installed from a file, a folder or npm by an older Flare doesn't run. It stays in Settings, Plugins, marked "Not from the Flare store", until it's uninstalled. If its author publishes it to the store, installing it from there replaces it.
Then Flare shows the install dialog described in Scopes and permissions.