Provision directory and packaging

Lay out the browser customization package, distribute default files and plugins, and distinguish installation data from instance data.

Provision is the browser's installation-side customization package. It supplies built-in plugins, package metadata, optional default authorization/configuration files, and fixed network rules. Each capability requires its License entitlement.

Find the root

Platform	Standard Chrovia location
Windows	`Chrovia` beside the browser executable
macOS	`Chrovia.app/Contents/Chrovia`
Linux	`Chrovia` beside the browser executable, when that distribution is available

Custom distributions may use a different directory name. Use the directory supplied with your actual distribution, not a guessed folder based on the user-data directory. On macOS it is under Contents, not under Contents/MacOS.

Chrovia/
  manifest.json
  Chrovia License
  Extended Preferences
  dnr_rules.json
  Extensions/
    chrovia-infra/
      manifest.json
      background.js
    my-plugin/
      manifest.json
      background.js
      index.html

The License, EP seed, and DNR file are optional according to your deployment. Keep existing plugin assets intact; the tree above shows roles, not every shipped file.

What each file does

File	Format and behavior
`manifest.json`	JSON object containing release metadata; not a Chrome extension manifest and not a plugin selection list
`Chrovia License`	Read-only fallback only when the user-data License is absent
`Extended Preferences`	Copied once into a user-data directory that has no EP file; never overwrites an existing instance file
`dnr_rules.json`	JSON array of fixed rules; requires `declarativeNetRequest`
`Extensions/<directory>/manifest.json`	Chrome extension manifest for one built-in plugin

A minimal package manifest is:

{
  "version": "1.0.0"
}

With instanceMetadata, authorized code can read it through chrovia.instanceMetadata?.provision?.manifest. Changing the package version does not change a plugin's version, License, or an existing EP file.

Shared installation, separate instances

Each --user-data-dir gets its own browser data. Instances launched from the same executable share the same Provision package. Putting a plugin in that installation makes it available to those instances; putting it inside a particular user-data directory does not install it as a Provision plugin.

For different plugin sets, prepare separate browser installations. Include only plugins supported by your SDK distribution.

Without Provision, the browser has no Provision plugins or Provision customization. A user-data License can still authorize kernel features, but a lease-based deployment also needs its working renewal integration.

URLs for built-in pages

Configuration that supports Provision URLs, such as navigation redirect, can refer to a plugin by directory name:

provision-extension://my-plugin/index.html

Use this form only in configuration that explicitly supports it. Other browser APIs may require an ordinary chrome-extension:// URL; obtain that URL from the installed extension. Keep the plugin directory name stable, and do not reuse an extension ID copied from another platform.

Package and update

Prepare the complete Provision tree for the intended product.
Copy it beside the executable or into the macOS bundle's Contents directory.
Install a valid License and, if required, a correctly signed EP file.
Fully restart the browser and verify installed plugins and configuration.

Changing the EP seed does not migrate existing user-data directories. Update their instance files explicitly and re-sign signed fields. Changing a fallback License does not replace a higher-priority user-data License.

Before replacing a package, back up your custom plugins and configuration. Verify that the final installed tree contains every intended plugin and, when used, dnr_rules.json at the root. Do not assume an update preserves files you added to an earlier installation.

Continue with installing and developing built-in plugins.