Skip to main content

Enterprise deployment

Two things decide how the extension reaches your people: how the binary is installed, and how it is pointed at the right backend. Everything on this page is what exists today.

No store listing during the closed beta

Nothing is published to the Chrome Web Store yet, so the managed force-install route is not available. Hand your users the ZIP from appilot.space/downloads and arrange the rollout with us first.

Installing​

Manual, the route that works today​

  1. Users download the ZIP from appilot.space/downloads.
  2. They unpack it into a folder they keep. Chrome loads the extension from that folder on every start, so a folder that gets cleared takes the extension with it.
  3. They open chrome://extensions, turn on Developer mode, choose Load unpacked, and select the folder.

There is no auto-update on this route. When a build stops being supported the backend answers 426 and the panel tells the user to fetch the current one, so plan a way to tell your people that a new ZIP is out.

Chrome Web Store, once the listing exists​

When the extension is listed, IT force-installs it from the Google Admin Console: Devices, Chrome, Apps and extensions, add the extension by its Web Store id, and set the installation policy to Force install. It then installs for every managed user with no action on their part, and it updates itself.

This is the route we are heading for, and it is the one to plan around for a large rollout. Talk to us about timing.

Pointing the extension at your own backend​

A downloaded build talks to the Appilot cloud. An on-premise deployment needs it pointed elsewhere, and there are two ways.

A managed policy​

Chrome's managed storage lets you set the API URL centrally, for every managed user, without repackaging anything:

{
  "3rdparty": {
    "extensions": {
      "EXTENSION_ID": {
        "policy": {
          "apiUrl": "https://api.appilot.internal.example.com",
          "accountUrl": "https://app.appilot.internal.example.com",
          "backofficeUrl": "https://backoffice.appilot.internal.example.com",
          "landingUrl": "https://appilot.internal.example.com"
        }
      }
    }
  }
}
KeyNames
apiUrlThe backend every request goes to
accountUrlThe My Account console, which is also where sign-in hands off, so it must belong to the backend above
backofficeUrlThe Backoffice, used by the in-context editor's links
landingUrlThe site carrying the downloads page, linked as <landingUrl>/downloads when a build has to be replaced

Every key is optional and an unset one keeps the build-time value, so a policy that only moves the backend sets only apiUrl. Each value must be an absolute http or https origin; anything else is dropped rather than used. The policy wins over a user's own development override, because it describes the deployment the machine belongs to.

The policy carries these four URLs and nothing else. Language, theme and privacy are per-user preferences, and what the assistant knows is your organization's configuration. Neither belongs in a device policy.

A build of your own​

From source, four build-time variables name the deployment the build belongs to: VITE_API_URL, VITE_ACCOUNT_URL, VITE_BACKOFFICE_URL and VITE_LANDING_URL. This is the route for an air-gapped environment where even the policy above cannot reach a central Chrome management. Ask us for the source drop.

Sign-in​

The extension collects no credentials. It opens My Account, the person signs in there with whatever their account uses, confirms the handoff, and the session travels back to the extension. So every method your organization has already works on the extension, corporate SSO included, with nothing to configure twice.

The one thing to arrange before a rollout: everyone needs an active membership in the organization that registered the domains they will use the assistant on. Invite them, or approve their join requests, first. A pending member signs in and is refused on the first turn.

What the extension does on a machine​

  • It mounts on pages the user visits, except Appilot's own hosts and any site the user paused from the context menu.
  • Page structure is read on the pages it mounts on. Field values are read only during a turn the user started, and never for password, one-time-code, payment-card or hidden fields.
  • Every request carries the build version. A build older than the supported minimum is blocked with a 426 and a message naming the download page, rather than failing in ways nobody can diagnose.
  • A turn belongs to the tab it started in, resolved when the user sends and re-checked on every action.