Plugins that can’t wreck your file

Plugins are the fastest way to make a design tool better. They are also the fastest way to lose a day of work. We wanted the first without the second.

Start with what a plugin is allowed to do

Every plugin ships a manifest that lists exactly what it needs. Read the document. Edit the selection. Show a panel. Write an export. If it is not on the list, it is blocked. There is no "full access" option.

Before a plugin runs, you see that list and can turn things off. Your answer is tied to the exact build you approved. If the plugin changes by a single byte, we ask again.

A signature proves who, not what

Publishers sign their packages with their own key, and we re-hash every file before trusting it. But a signature only tells you who made something. It never grants access on its own. Permissions do that.

We pick the sandbox

Plugins run in a dedicated worker, a sandboxed frame, or an isolated sandbox. The plugin does not get a say. Each call has limits on time, memory, and rate. Blow through them and the call is cut off. Keep doing it and the plugin is turned off.

Changes go through undo

A plugin cannot poke at your file directly. It proposes changes using the same commands the app uses, like moving a layer or setting its opacity. Those land in your normal history, labeled with the plugin that made them. A failed or stale call never gets that far.

Updates you can take back

Pin a version or let updates install on their own. If one misbehaves, roll back to the exact build you had, with its settings. A bad update is quarantined and your working version stays put. And if something goes really wrong, safe mode starts Varial with only built-in code.