How Central Configuration Works

A central configuration has four parts:

• The configuration plugin: a Lua file named plugin.lua. It declares your providers, chat templates, profiles, and other objects, and the settings you want to preset or lock.
• The archive: a ZIP file named after the configuration ID. Besides the configuration plugin, it may hold an icon and further plugins, such as assistant plugins or model plugins.
• The configuration server: an ordinary web server in your intranet that serves the archives. See Configuration Server.
• The metadata on each device: the configuration ID and the address of the server, plus, if you encrypt API keys, an encryption secret. AI Studio reads them from the Windows registry, from policy files, or from environment variables.

flowchart LR
    subgraph Device["Each device"]
        M["Metadata<br/>registry, policy files,<br/>or environment variables"] --> A["AI Studio"]
    end
    A -- "GET {server}/{id}.zip<br/>at start and every 16 minutes" --> S["Configuration server<br/>in your intranet"]
    S -- "configuration plugin<br/>and further plugins" --> A
    A --> R["Providers, templates, settings:<br/>locked or preset"]

Loading

What happens on a device

1. When AI Studio starts, it reads the metadata: pairs of a configuration ID and a server address, and the encryption secret, if there is one.
2. For each pair, it requests {server address}/{configuration ID}.zip from your server.
3. It extracts the archive below its data directory, into plugins/.config/{configuration ID}/, and loads every plugin in it.
4. It applies the configuration right away: your providers appear, and your settings take effect.
5. Every 16 minutes, AI Studio reads the metadata again and asks the server whether an archive changed. It downloads only the archives that changed and applies them while it runs.

Because AI Studio reads the metadata again in each cycle, you can add or remove a configuration on a device without a restart. If the server can't be reached, AI Studio keeps the version it already has.

The "Information" page in AI Studio shows whether a device runs with a configuration of your organization, which configuration IDs it found, and where it found them. Start there when something doesn't work as expected.

Configuration IDs

• Each configuration has an ID in the form of a GUID, such as 9072b77d-ca81-40da-be6a-861da525ef7b. Create a new one for each configuration.
• AI Studio always writes the ID in lowercase, also in the address it requests. Name the archives on your server in lowercase.
• The ID in the configuration plugin must be the same ID that you store on the devices. Otherwise, the "Information" page reports an ID mismatch.
• Treat the IDs like a password. A configuration may contain API keys or the addresses of internal services. Whoever knows an ID can download that configuration from your server.

ID = "9072b77d-ca81-40da-be6a-861da525ef7b"
DEPLOYED_USING_CONFIG_SERVER = true

Several configurations

A device can load many configurations at the same time, up to 100,000. This allows layered setups, such as one configuration for the whole organization and one per department or project. You store each configuration in a slot of its own, for example, the registry values config_id_00000 and config_server_url_00000, then config_id_00001 and config_server_url_00001, and so on.

The slots decide which configurations a device loads, not which one wins. When two of your configurations manage the same setting or define the same object, such as the same LLM provider, their PRIORITY decides:

PRIORITY = 100

A configuration with a higher priority is applied later and therefore wins. Without the field, the priority is 0. A typical layered setup:

Configuration	PRIORITY	Role
Organization-wide base	0	Providers, update behavior, and security settings for everybody
Department	100	Refines the base, for example, a different default provider
Project or lab	200	Refines the department configuration

A configuration overrides only what it defines. Everything else keeps the value of the configuration below it. Give two configurations that override each other different priorities: with equal priorities, the order stays the same across restarts, but you can't tell in advance which one wins.

Lists replace, they don't merge

When a setting holds a list or a table, the winning configuration replaces the whole list. A department configuration that lists one entry drops all entries of the base configuration. This is on purpose: it is the only way a department can take something back.

Watch these settings in particular:

Setting	What a partial list costs you
DataApp.HiddenAssistants	Assistants hidden by the base configuration become visible again
DataApp.ProhibitedProviders	Providers prohibited by the base configuration become usable again
DataSourceSecuritySettings.TrustedProviderIds	Providers trusted by the base configuration lose that status
DataApp.ExternalHttpCustomRootCertificateAllowedHosts	Hosts of the base configuration no longer trust your root certificates
DataConfidence.CustomConfidenceScheme	Providers left out get the confidence level "Unknown"
DataChat.PreselectedDataSourceIds	Data sources preselected by the base configuration are no longer preselected

The rule of thumb: when a configuration with a higher priority sets one of these, it must repeat every entry it wants to keep.

Two settings add up instead:

• DataApp.EnabledPreviewFeatures: enable one preview feature for everybody and another one for a department, and that department gets both.
• DataAssistantPluginAudit.EnterpriseApprovedPlugins: a department can approve further assistant plugins without repeating the approvals of the base configuration.

Where AI Studio looks for the metadata

AI Studio knows three sources for the metadata. It checks them in this order and uses the first source that contains at least one complete pair of an ID and a server address. It doesn't merge the sources:

Operating system	Order
Windows	Registry → policy files → environment variables
Linux	Policy files → environment variables
macOS	Policy files → environment variables

The encryption secret is looked up on its own: AI Studio takes it from the first source that contains one, even if that source holds no configuration. A pair with only an ID or only a server address is skipped with a warning in the log. When the same ID appears in two slots of one source, the first slot wins.

The pages Deploying on Windows, Deploying on Linux, and Deploying on macOS show where each source lives.

Policy files

Policy files work on every operating system and have the same format everywhere. Each configuration gets a file of its own, named after its slot, from config_00000.yaml to config_99999.yaml:

id: "9072b77d-ca81-40da-be6a-861da525ef7b"
server_url: "https://intranet.example.org/ai-studio/configuration"

The encryption secret, if you need one, goes into config_encryption_secret.yaml:

config_encryption_secret: "BASE64..."

The files look like YAML, but AI Studio reads only a simple subset of it:

• one key: value per line; quotes around the value are optional;
• comments only as whole lines starting with #. A # after a value becomes part of the value;
• file names exactly as shown, in lowercase, with the extension .yaml;
• a single line AI Studio can't read invalidates the whole file, and the log names the line.

When AI Studio reads several policy folders, as on Linux, it combines them slot by slot, and the first folder that holds a value for a slot wins.

Environment variables

Environment variables are the last fallback on every operating system:

MINDWORK_AI_STUDIO_ENTERPRISE_CONFIG_ID_00000=9072b77d-ca81-40da-be6a-861da525ef7b
MINDWORK_AI_STUDIO_ENTERPRISE_CONFIG_SERVER_URL_00000=https://intranet.example.org/ai-studio/configuration
MINDWORK_AI_STUDIO_ENTERPRISE_CONFIG_ENCRYPTION_SECRET=BASE64...

Older formats

AI Studio still reads the formats of earlier versions, so you can migrate step by step. Within one source, it reads the slots first, then the older formats:

• Slots without an underscore or with fewer digits, such as config_id0 or config_id_1. Slots are matched exactly: config_id_1, config_id_01, and config_id_00001 are three different slots.
• The combined format id1@url1;id2@url2;… in the registry value configs or the variable MINDWORK_AI_STUDIO_ENTERPRISE_CONFIGS.
• A single configuration in the registry values config_id and config_server_url, or the variables MINDWORK_AI_STUDIO_ENTERPRISE_CONFIG_ID and MINDWORK_AI_STUDIO_ENTERPRISE_CONFIG_SERVER_URL.

Use five-digit slots with an underscore for new deployments.

Locked settings and defaults

Every setting that you set in CONFIG["SETTINGS"] is locked: users see your value and can't change it. To offer a value as a default instead, which users may change, add AllowUserOverride:

CONFIG["SETTINGS"]["DataApp.StartPage"] = "CHAT"
CONFIG["SETTINGS"]["DataApp.StartPage.AllowUserOverride"] = true

AllowUserOverride doesn't apply to settings that hold a set of values. These stay locked: DataApp.HiddenAssistants, DataApp.ProhibitedProviders, DataSourceSecuritySettings.TrustedProviderIds, DataTools.DisabledToolIds, and DataApp.ExternalHttpCustomRootCertificateAllowedHosts.

Objects such as providers, chat templates, profiles, and data sources that you roll out are read-only for users. Users can still add their own, unless you prevent that, for example, with DataApp.AllowUserToAddProvider.

Who may change what

• Your configurations always win against local ones. Users may import configuration plugins themselves, unless you prevent it with DataApp.AllowUserToImportConfigurationPlugins. Such a local plugin is always applied after yours, whatever priority it declares, and it can't take over a setting or an object of your configurations.
  • Requires AI Studio v26.11.1 or newer for the tool tables DataTools.LockedToolSettings, DataTools.DefaultToolSettings, and DataTools.MinimumProviderConfidenceByToolId. In older versions, a local plugin can change their entries, for example, lower the minimum confidence of a tool.
• Everything you deploy is protected. Users can't delete, edit, share, or replace a plugin that came from your configuration server.
• Mark your plugins. Set DEPLOYED_USING_CONFIG_SERVER = true in every plugin you deploy. Inside the archive, the location already proves that a plugin belongs to your organization. When you place a plugin elsewhere, for example, with your device management into the regular plugin directory of AI Studio, this field is the only thing that protects it.
• Plugin IDs must be unique. If a local plugin has the same ID as one of yours, AI Studio keeps yours and logs a warning.

Withdrawing a configuration

When you remove a configuration from a device, AI Studio removes what it brought along: its providers, data sources, profiles, chat templates, its approvals for assistant plugins, and every further plugin from its archive.

For settings, AI Studio remembers the value each setting had before your configuration took it over, and hands it back:

• Somebody who had chosen a start page before you set one gets their start page back, not the AI Studio default.
• When a setting still had its default at the moment you took it over, the default returns.
• When you offered a setting as a default with AllowUserOverride and the user changed it, the user keeps their value.

A configuration that is still deployed but can't be loaded, for example, because of an error in its Lua code, is not withdrawn. Everything it brought along stays until you actually remove it.

Where to go next

• Configuration Server
• Enterprise IT