Enterprise

Status: partly implemented. Astela reads policies from all three operating systems; the rest of this page is design. See implementation status.

Astela is designed to be manageable: every setting can be set and locked by policy, and the browser will ship with an MSI package, silent installation, update control, a diagnostics page and a safe mode. Organizations will get all of this without telemetry and without an account.

The decisions behind this design are recorded in ADR 0003 (packaging with electron-builder), ADR 0012 (policy providers per OS) and ADR 0014 (update architecture with a signed feed). See the decision records.

Related documents:

• Settings, policies and themes: how settings and policies are defined, resolved and generated.
• Updates: the signed update feed, channels and rollback.
• Security: permissions, certificates and network hardening.
• Testing: how the policy providers and packages are tested.

Policy sources

Platform	Source	Typical delivery
Windows	Registry keys HKLM\SOFTWARE\Policies\Astela and HKCU\SOFTWARE\Policies\Astela for mandatory policies; HKLM\SOFTWARE\Policies\Astela\Recommended and HKCU\SOFTWARE\Policies\Astela\Recommended for recommended policies.	Group Policy with the ADMX/ADML templates, Microsoft Intune.
macOS	Managed preferences (/Library/Managed Preferences) for the bundle ID io.github.secoolioo.astela.	Configuration profiles through MDM, for example Jamf.
Linux	/etc/astela/policies/managed/*.json for mandatory policies and /etc/astela/policies/recommended/*.json for recommended policies. Files are merged in alphabetical order.	Any tool that can place files on the system.

The ADMX namespace is Astela.Policies. The namespace, the registry paths, the bundle ID and the Linux paths derive from brand.json and never change once released.

Policy names follow Chrome’s names where that makes sense, so that existing knowledge and tooling carry over.

Precedence

• Mandatory over recommended. A mandatory policy locks a setting; a recommended policy only changes the value users start from.
• Machine over user. On Windows, HKLM takes precedence over HKCU.
• Sensitive policies only from trusted sources. The update URL (UpdateURL), the proxy policies, the default search provider policies and, from M4, extension sources apply only from HKLM on Windows and only as forced values on macOS. Linux policy files are system-wide by location. If a sensitive policy appears anywhere else, it will not apply, and the diagnostics page will show a warning. This keeps a program running as the user from redirecting updates or traffic by writing to HKCU. Chrome and Firefox follow the same principle (as of October 2026).

How policies combine with defaults, user values and workspace overrides is described in the resolution order.

Reading policies

In M1, Astela reads every policy source without a native module while Electron starts (ADR 0025):

• Windows: reg export writes the policy keys of HKLM and HKCU to temporary files, both at the same time, which are then parsed. The export is UTF-16LE, so non-ASCII characters survive intact.
• macOS: plutil -convert xml1 -o - converts the managed preferences plists to XML, which is then parsed. XML is used instead of JSON because plist dates and binary data (<date> and <data>) cannot be converted to JSON.
• Linux: the JSON files are read directly.

Until the sources have been read, the last known policy set applies. It is cached in the profile and also serves as the fallback when a source cannot be read. The first window waits for the fresh set; only a start without a cache reads the sources before the app is ready. Policies are read again, in the background, when a window gains focus, except while the first window opens, and every 15 minutes.

In M5, a native Node-API addon is planned. It will use RegisterGPNotification on Windows to be notified of Group Policy changes and CFPreferencesAppValueIsForced on macOS to tell forced values apart.

M1 policy set

M1 is designed to ship about 22 policies:

Group	Policies
Update	UpdatePolicy, TargetChannel, TargetVersionPrefix, UpdateURL (mirror), AutoUpdateCheckPeriodMinutes
Network	ProxyMode, ProxyPacUrl, ProxyServer, ProxyBypassList, DnsOverHttpsMode, DnsOverHttpsTemplates, AuthServerAllowlist
Content	URLBlocklist, URLAllowlist, HomepageLocation, RestoreOnStartup with RestoreOnStartupURLs, NewTabPageLocation, the DefaultSearchProvider* policies
Features	PrivateModeAvailability, DeveloperToolsAvailability, DownloadDirectory, PromptForDownloadLocation, SafeModeAvailability, and <Module>Enabled for every optional module (for example WorkspacesEnabled)
Locks	Every setting with a policy attribute is automatically a policy. In addition, ManagedSettings takes JSON that sets settings by key, each with a Status of locked or default.

UpdatePolicy takes one of three values:

Value	Meaning
0	Off. The in-app updater does not run.
1	Automatic. Updates are checked, downloaded and installed as described in Updates.
2	Manual only. Updates are not applied automatically; they run only when started by hand.

TargetChannel selects stable or beta. TargetVersionPrefix pins updates to the highest version in the feed that matches the prefix. UpdateURL points the browser to a mirror of the update feed and packages.

Later policy groups

Milestone	Policies
M2 Flow	HttpsOnlyMode, AuthNegotiateDelegateAllowlist, ManagedBookmarks, SpellcheckDictionaryURL, cookie policies, ClearBrowsingDataOnExit, PasswordManagerEnabled, import policies, CACertificates, SSLErrorOverrideAllowed, capture policies and printing policies. Also a Jamf JSON schema.
M4 Ecosystem	Extension policies, for example ExtensionInstallBlocklist.
M5 Enterprise+	RollbackToTargetVersion and an update maintenance window, as part of an extended set of more than 50 policies.
M6 Sync and 1.0	Sync policies.

Network: proxy, DNS, certificates and single sign-on

Proxy

The proxy defaults to the system configuration. When the proxy policies are set, the browser is designed to apply them through session.setProxy and then close all existing connections (closeAllConnections), so no connection keeps using the old route.

DNS over HTTPS

Electron starts with DNS over HTTPS turned off (as of October 2026), so Astela is designed to configure the host resolver explicitly (configureHostResolver). The default is automatic with a list of providers. With DnsOverHttpsMode, administrators can choose off or secure, and DnsOverHttpsTemplates sets their own resolver templates.

Certificates

• Astela is designed to trust the Chrome Root Store plus root certificates that are trusted locally by the operating system.
• On Windows and macOS, locally trusted roots are picked up automatically. On Linux, they come from the NSS database; the admin guide will document the certutil steps.
• Client certificates are never selected automatically; the user always chooses one.
• Certificate errors lead to Astela’s own interstitial page.
• From M2, CACertificates and SSLErrorOverrideAllowed give administrators direct control.

The root store, CRLSet and certificate transparency data are updated only with Electron updates. This is why Astela commits to a fixed response time for security updates, described in Security.

Single sign-on

Kerberos (Negotiate) and NTLM are designed to work through allowlist policies together with Electron’s allowNTLMCredentialsForDomains:

• AuthServerAllowlist will be mapped internally to Electron’s command-line switch auth-server-whitelist (as of October 2026). The switch has to be set before the app is ready, so it takes the policy state that applies then: the last known set, or on the first start of a profile the freshly read one. A changed value takes effect after a restart.
• From M2, AuthNegotiateDelegateAllowlist will be mapped the same way to auth-negotiate-delegate-whitelist (as of October 2026).

Network tests

The network features are designed to be tested automatically:

• every proxy mode, including a local PAC file, against a test proxy;
• DNS over HTTPS against a local DNS over HTTPS stub;
• Kerberos and Negotiate against an MIT KDC and a web server in a container on Linux;
• a custom root certificate authority in the Windows certificate store and in the NSS database on Linux.

MSI package

Astela is designed to ship a native MSI package (not a wrapped installer) for managed Windows deployments:

• Per machine. perMachine: true installs for all users (ALLUSERS=1).
• Fixed upgrade code. The upgradeCode is set explicitly and never changes. Major upgrades replace the previous version, with downgrade protection.
• Silent. Silent installation runs msiexec /i with /qn /norestart /l*v and needs no restart.
• Properties. INSTALLDIR sets the installation folder, and DESKTOP_SHORTCUT=0 turns off the desktop shortcut. Both are added through electron-builder’s msiProjectCreated hook, already in M1.
• Install type marker. The installation type is recorded outside the policy keys, at HKLM\SOFTWARE\Astela\Install with Type=msi. When the browser finds it, the in-app updater will stay off; IT distributes new MSI packages, for example through Group Policy, Intune or SCCM, and controls update behavior with UpdatePolicy.
• Rollback. Rollback is an IT task; the ALLOWDOWNGRADE property allows a deliberate downgrade.
• Clean uninstall. Uninstalling removes the installation cleanly. Intune detection by ProductCode will be documented.
• Stable releases only. Windows Installer ignores prerelease identifiers in version numbers, so beta releases are not published as MSI.
• x64 in M1. For arm64, electron-builder produces an MSI that is marked as x64 (as of October 2026). A dedicated WiX template is designed to follow in M5; until then, arm64 devices use the NSIS installer.

In M5, an optional elevated update task (running as SYSTEM) is designed to install verified MSI packages silently.

Diagnostics page

The diagnostics page (app://diagnostics) is designed to show everything support and administrators need, without sending anything anywhere:

Section	Contents
Version	App, Electron, Chromium, Node and V8 versions; update channel; installation type; paths; command line.
Policies	For each policy: value, source, scope, level, status and error. A button to reload policies and a JSON export.
Modules	Which modules are active and how long they took to load.
Updates	Updater status, feed and signature state.
Processes	Process metrics.
Support	Copy as text or JSON (redacted) and a diagnostics ZIP file including the logs. Nothing is sent automatically.

Logs are designed to be local only: JSON Lines files under logs/, rotated at 5 MB with three files kept. Crash dumps also stay local; they can be viewed on the diagnostics page and shared manually.

Safe mode

Safe mode is designed to help when a module, a theme or the GPU prevents normal use:

• Start: with --safe-mode, a Jump List entry on Windows, a .desktop action on Linux or the Dock menu on macOS. From M2, the browser is designed to enter safe mode automatically after two failed starts that were not preceded by an update.
• Effect: optional modules and custom themes are turned off, and optionally GPU acceleration as well. The security guards in the kernel stay active, so permissions remain denied by default.
• Control: administrators can turn safe mode off with SafeModeAvailability.

Accessibility

• Target: WCAG 2.2 AA for Astela’s own user interface, and EN 301 549 clause 11.
• Test matrix: NVDA, JAWS, Narrator, VoiceOver and Orca; Forced Colors; keyboard-only use; target size of at least 24 × 24 px.
• Manual checks: maintainers run a screen reader smoke test with NVDA, VoiceOver and Orca once per minor release.
• Conformance report: a VPAT 2.5 INT is planned from M5.

The visual rules behind these targets are described in the design system.

Outgoing connections

By design, Astela collects no telemetry and uploads no crash reports. Every outgoing connection is designed to be documented, listed on the diagnostics page, and redirected or turned off by policy:

• Updates: the update feed on the project website and the packages on GitHub Releases.
• Content blocker (M2): the filter list feed.
• Spell checking: dictionaries are self-hosted from M2. In M1, spell checking is off on Windows and Linux, so nothing reaches third-party dictionary servers; macOS uses the system spell checker.
• Search suggestions: opt-in.

Admin guide

An admin guide (v1) is planned for M1. It will cover:

• Installation: MSI, NSIS, macOS (dmg, without a .pkg installer), deb and rpm, including silent installation flags.
• Policy reference: generated from the setting and policy definitions, with examples for Group Policy, Intune (ADMX import and OMA-URI), Jamf and Linux.
• Updates: update control and running a mirror.
• Network: proxy, certificates and single sign-on.
• Operations: logs, the diagnostics page, safe mode and the list of outgoing connections.

Acceptance criteria

The M1 acceptance tests for enterprise features are:

• The MSI installs, upgrades and uninstalls silently per machine, each with exit code 0.
• Policies set through the registry, plists and JSON files take effect and appear on app://diagnostics.
• Settings locked by policy cannot be changed in the UI or through the API and are shown as managed.
• The ADMX/ADML templates validate against the XSD automatically. Maintainers check the import into a Microsoft Intune test tenant manually once per minor release.
• --safe-mode starts without optional modules and custom themes.
• The policy providers are tested against real sources: a test key under HKCU on Windows, a plist in /Library/Managed Preferences on macOS and JSON files in a temporary folder on Linux.

Implementation status

Implemented (app/src/platform/policy/), with unit tests against recorded registry exports, plists and JSON files:

• Windows: reg export of HKLM and HKCU\SOFTWARE\Policies\Astela; values of the Recommended subkey are recommended, and a subkey named after a policy holds a list.
• macOS: the machine-wide and the per-user managed preferences of the bundle id under /Library/Managed Preferences, converted with plutil and read by a small plist parser; all values there are mandatory.
• Linux: /etc/astela/policies/managed/*.json and /etc/astela/policies/recommended/*.json, merged in alphabetical order; invalid files are reported and skipped.

The update policies (UpdatePolicy, TargetChannel, TargetVersionPrefix, UpdateURL and AutoUpdateCheckPeriodMinutes) are implemented; see updates.md.

Also implemented:

• SetupGuideEnabled (boolean): false as a mandatory policy keeps the setup guide from opening on the first start of a profile. Starting the browser with --no-first-run does the same for one start.
• BookmarkBarEnabled (boolean): shows or hides the bookmarks bar, as mandatory or recommended policy, like the setting bookmarks.bar.
• ApplicationLocaleValue (string): the language of the menus, dialogs and pages of the browser, as mandatory or recommended policy, like the setting i18n.language: system, or a language code such as en or de; a code without a translation shows English. Unlike in Chromium, a code with a region, such as de-DE, is not valid. A change takes effect when the browser starts again.
• DefaultBrowserSettingEnabled (boolean): false as a mandatory policy keeps users from making Astela the default browser. The default browser setting on the settings page and in the setup guide then shows that the organization manages it and has no Make default button, and the browser refuses the change.
• ImportEnabled (boolean): false as a mandatory policy turns off the import from other browsers. The settings page and the import step of the setup guide then say that the organization turned it off instead of listing the browsers, and the browser refuses an import.
• PrivateModeAvailability (0 or 1): 1 as a mandatory policy keeps people from opening private windows; the shortcut and the item in the menu bar of macOS then do nothing, and the browser menu has no New private window. 0 allows them. Forcing every window to be private, which other browsers do with 2, is not supported yet; the browser reports 2 as an invalid value.
• DeveloperToolsAvailability (0, 1 or 2): 2 as a mandatory policy keeps the developer tools closed; F12, the Inspect item of the context menu and the View menu of macOS then do nothing. 0 and 1 allow them for web pages, as in Chromium; the browser’s own pages never get them. See page tools.
• SSLErrorOverrideAllowed (boolean): false as a mandatory policy keeps users from continuing to a site whose certificate is not trusted; the warning then offers only the way back, and certificates accepted earlier in the session are refused again.
• ContentBlockerEnabled (boolean): turns the content blocker on or off, as mandatory or recommended policy.
• ContentBlockerCookieNoticesEnabled and ContentBlockerAnnoyancesEnabled (boolean): turn the optional lists of the content blocker against cookie notices and against annoyances on or off, as mandatory or recommended policy, like the settings contentBlocker.cookieNotices and contentBlocker.annoyances.
• TabStripPosition (top, bottom, left or right): sets or recommends where the tab strip is, like the setting tabs.position.
• DefaultSearchProviderSearchURL: the search address of the address bar and the new tab page; as a sensitive policy it applies only from machine-wide mandatory sources.

The MSI package (x64, per machine, with the fixed upgrade code) is built for every pull request and installed and removed silently in CI.

Not implemented yet: the MSI properties, the install-type marker, the M1 policy set beyond the first settings, the diagnostics page, generated templates, safe mode and the admin guide.