# Applane docs > Every page of the Applane documentation in one file, in sidebar order. The per-page index is llms.txt. Last updated: 2026-08-29 # What Applane is > Applane is a Chrome extension that turns a plain-language description into an internal web app deployed to Google Apps Script in your own Workspace. Source: https://docs.applane.dev/ Applane is a Chrome extension. A person on your team opens its side panel, describes an internal tool in plain words, and iterates with an AI agent until a working web app is deployed. The app runs on Google Apps Script, inside your Google Workspace, under the account of whoever opens it. The model runs on Vertex AI in your own GCP project. Every Google call is made from the browser with the employee's own token. Applane's backend stores your company's configuration, the email addresses of the people who build, and your invoice. It never receives a Google access token, a line of app source, a prompt, or a row of your data. Setting it up touches three places: the Google Admin console, one GCP project, and the Applane console. This site is split by who does each part. ## Pick your role - [Google Workspace admin](https://docs.applane.dev/workspace-admins/prerequisites/): Chrome extension policy, Apps Script, accounts and groups, Drive sharing, offboarding. - [GCP admin](https://docs.applane.dev/gcp-admins/prerequisites/): One project with billing, five APIs, one IAM grant, an Internal consent screen and a web OAuth client. - [Applane admin](https://docs.applane.dev/console/sign-up/): Sign up, verify your domain, run the setup checker, manage seats and billing. - [Builder](https://docs.applane.dev/builders/install-and-sign-in/): Install the extension, sign in, build and share your first app. ## For AI agents Every page has a **Copy as Markdown** button next to its title, and is served as Markdown at the same path with a `.md` suffix (for example `/gcp-admins/oauth-client.md`). The whole site is at [/llms.txt](https://docs.applane.dev/llms.txt) (an index, one line per page) and [/llms-full.txt](https://docs.applane.dev/llms-full.txt) (every page in one file). Cache these files; re-fetch when the Last updated line or the ETag changes. ## Before you start - [What runs where](https://docs.applane.dev/start/what-runs-where/): one diagram of the three places Applane runs. - [Who does what](https://docs.applane.dev/start/who-does-what/): every step, who owns it, and how long it takes. - [The one-hour setup path](https://docs.applane.dev/start/one-hour-setup/): the order to do it in when one person has every right. --- # What runs where > Applane runs in three places: the employee's Chrome, your Google (Workspace plus one GCP project), and Applane's backend, which holds config and licences. Source: https://docs.applane.dev/start/what-runs-where/ Applane runs in three places. Two of them are yours. _Diagram: https://docs.applane.dev/start/what-runs-where/_ | Place | What runs there | Who owns it | |---|---|---| | The employee's Chrome | The extension: side panel, the agent loop, the sandbox preview, chat history and drafts in browser storage. | Your company (managed Chrome profiles). | | Your Google | The OAuth client the employee signs in with. The Apps Script projects that are the apps. Vertex AI, which runs Gemini and bills to your project. Drive, Sheets and Docs, which the apps read and write as the viewer. | Your company (Workspace organisation and one GCP project). | | Applane | The tenant record (your domain, your OAuth client id, your settings), the seat list, the licence signer, the admin console, billing. | Applane (Supabase in Frankfurt, Cloudflare, Stripe). | ## What crosses the lines The extension calls your Google with the employee's own OAuth token, minted by your OAuth client. That token reaches the Apps Script API, Vertex AI, Sheets, Drive and Docs, and Applane never sees it. The extension sends Applane two things: your domain name, to find the tenant, and a Google ID token, to prove who is signing in. The ID token is discarded after the check. Applane sends back the tenant configuration and a signed licence. The admin console sends Applane what an admin types into it, plus pass or fail results from the setup checker. Nothing else crosses. No app source, no prompt, no sheet row, no Drive file. The full list is in [Data flow](https://docs.applane.dev/security/data-flow/). --- # Who does what > Applane setup is eight steps across four roles: Applane admin, DNS owner, GCP admin and Workspace admin. About an hour for one person with every right. Source: https://docs.applane.dev/start/who-does-what/ Four roles touch the setup. One person can hold all four; in most companies they are three people with ticket queues. | Role | What they need | Steps | Time | |---|---|---|---| | Applane admin (whoever signs up) | A Google work account at your domain | Sign up, create the company, paste the values, run the checker | 15 min | | DNS owner | Access to your domain's DNS | Add one TXT record | 5 min, plus the ticket | | GCP admin | Owner or editor on one GCP project in your organisation | APIs, IAM, budget, consent screen, OAuth client | 20 min | | Google Workspace admin | Super admin in the Google Admin console | Chrome extension policy, Apps Script check, two identities, Drive sharing | 15 min | | Builder | A Workspace account in the builders group | Install, sign in, turn on the Apps Script API once, build | 15 min for the first app | ## The steps, in order | # | Step | Who | Time | Where | Page | |---|---|---|---|---|---| | 1 | Sign up and create the company | Applane admin | 2 min | Applane console | [Sign up](https://docs.applane.dev/console/sign-up/) | | 2 | Add the `applane-verify` TXT record | DNS owner | 5 min + queue | Your DNS provider | [Verify your domain](https://docs.applane.dev/console/verify-domain/) | | 3 | Enable five APIs, grant one role, add a budget alert | GCP admin | 10 min | Terminal or Cloud Shell | [Set up the project](https://docs.applane.dev/gcp-admins/setup/) | | 4 | Consent screen (Internal) and OAuth client (Web application) | GCP admin | 5 min | Google Cloud console | [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/), [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) | | 5 | Allow or force-install the extension; create the bot account and admin group | Workspace admin | 15 min | Google Admin console | [Chrome extension policy](https://docs.applane.dev/workspace-admins/chrome-extension-policy/), [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/) | | 6 | Paste the project id, client id, group and bot into the console; run the checker | Applane admin | 5 min | Applane console | [Setup checklist](https://docs.applane.dev/console/setup-checklist/) | | 7 | Install, sign in, turn on the Apps Script API | Builder | 3 min | Chrome | [Install and sign in](https://docs.applane.dev/builders/install-and-sign-in/) | | 8 | Build and deploy the first app | Builder | 10 min | The extension | [Your first app](https://docs.applane.dev/builders/first-app/) | Steps 2 to 5 do not depend on each other. Step 6 waits on all of them; step 7 waits on step 2 (the extension cannot find your tenant until the domain is verified). With one engaged person who has every right, the whole thing takes about an hour. Across three teams with ticket queues, expect one to two weeks, almost all of it waiting. --- # The one-hour setup path > The fastest order for Applane setup when one person holds every right: DNS first, then groups, GCP project, OAuth, Chrome policy, checker, first app. Source: https://docs.applane.dev/start/one-hour-setup/ This is the order that avoids waiting. Do step 1 first because DNS takes the longest to show up; everything else runs while it propagates. 1. **Sign up** at the Applane console with your work account and create the company. 2 minutes. [Sign up](https://docs.applane.dev/console/sign-up/) 2. **Add the TXT record** the console shows you. 5 minutes. [Verify your domain](https://docs.applane.dev/console/verify-domain/) 3. **Create the builders group** `applane-builders@` in the Google Admin console, plus `applane-admins@` and the `applane-bot@` account. 5 minutes. [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/) 4. **Prepare the GCP project.** Open in Cloud Shell, or run the script. 10 minutes. [Set up the project](https://docs.applane.dev/gcp-admins/setup/) 5. **Consent screen and OAuth client** in the Google Cloud console. 5 minutes. [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/), [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) 6. **Allow or force-install the extension** in the Google Admin console. 5 minutes. [Chrome extension policy](https://docs.applane.dev/workspace-admins/chrome-extension-policy/) 7. **Paste the values into the console and run the checker.** 5 minutes. [Setup checklist](https://docs.applane.dev/console/setup-checklist/) 8. **Install the extension and sign in yourself.** Turn on the Apps Script API when the extension asks. 3 minutes. [Install and sign in](https://docs.applane.dev/builders/install-and-sign-in/) 9. **Build one app.** 10 minutes. [Your first app](https://docs.applane.dev/builders/first-app/) If the DNS record has not propagated by step 8, the extension shows `unknown_domain`. Wait and try again; nothing else needs redoing. See [Error messages](https://docs.applane.dev/reference/errors/). --- # What does Google Workspace need for Applane? > A Workspace edition with Apps Script and Chrome management, Apps Script on as a core service, and a GCP project inside the same organisation. Source: https://docs.applane.dev/workspace-admins/prerequisites/ **Who:** Google Workspace super admin **Time:** 5 minutes to check Applane needs three things from your Workspace. Two are on by default. | Requirement | Why | Where to check | |---|---|---| | A Google Workspace edition that includes Apps Script and Chrome management | The apps are Apps Script projects. Chrome management is how you allow or force-install the extension. | Business Starter and above, Enterprise, Education, and Nonprofits all include both. | | **Apps Script** on as a core service for the organisational units that will build | The extension creates and deploys Apps Script projects with the builder's own account. | **Apps > Google Workspace > Apps Script**. It is on by default; confirm nobody turned it off for a sub-OU. | | Your GCP project inside the same Workspace organisation | The OAuth consent screen can only be set to Internal when the project belongs to an organisation. Internal is what removes Google's app verification. | Your GCP admin checks this in [Prerequisites for GCP admins](https://docs.applane.dev/gcp-admins/prerequisites/). | ## Your six tasks 1. [Allow or force-install the extension](https://docs.applane.dev/workspace-admins/chrome-extension-policy/) 2. [Apps Script API per-user setting](https://docs.applane.dev/workspace-admins/apps-script-api/) 3. [Third-party app access](https://docs.applane.dev/workspace-admins/third-party-app-access/) 4. [Accounts and groups to create](https://docs.applane.dev/workspace-admins/accounts-and-groups/) 5. [Drive sharing policies](https://docs.applane.dev/workspace-admins/drive-sharing/) 6. Later: [Offboarding an employee](https://docs.applane.dev/workspace-admins/offboarding/) and [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/) None of them depends on the GCP side. The Applane admin ticks them off in the [setup checklist](https://docs.applane.dev/console/setup-checklist/) once you are done. --- # How do I force-install the Applane extension with Google Admin? > Add the Applane extension id in the Google Admin console Chrome settings and choose Force install or Allow install. The same policy as JSON is on the page. Source: https://docs.applane.dev/workspace-admins/chrome-extension-policy/ **Who:** Google Workspace admin with Chrome management rights **Time:** 5 minutes Many companies run Chrome with "block every extension not on a list". Applane's extension id must be on that list, either as allowed (people install it themselves from the Chrome Web Store) or as force-installed (it appears in every managed Chrome in the organisational unit). The extension id is shown in the Applane console under **Setup > Workspace admin**. It is written `` below. ## In the Google Admin console 1. Open **Devices > Chrome > Apps & extensions > Users & browsers**. 2. Pick the organisational unit. Start with a pilot OU, then widen. 3. Click **+** (bottom right) and choose **Add Chrome app or extension by ID**. 4. Paste ``. Leave the source as the Chrome Web Store. 5. Set the installation policy: - **Force install** for a rollout. Silent install, not removable, on every managed Chrome profile in the OU. Tick **Pin to browser toolbar** so the icon is visible. - **Allow install** for a pilot. Employees install it from the Chrome Web Store listing. This is the minimum if your policy blocks unlisted extensions. 6. Save. Force-install reaches managed browsers and profiles: employees signed in to Chrome with their work account under Chrome Browser Cloud Management. It does not reach a personal Chrome, and it does not need to; sign-in checks the account's domain either way. ## Pin the tenant domain (optional) The extension has one managed-storage setting, `tenantDomain`. When it is set, the extension skips the "what is your work email" prompt and goes straight to your sign-in. It is a hint, not trust: sign-in still checks the account's domain. In the same policy screen, open the extension's entry and paste this into **Policy for extensions**: ```json { "tenantDomain": "" } ``` ## The same policy as JSON If you manage Chrome policy as JSON (Chrome Browser Cloud Management custom policies, or a policy file on Windows, macOS or Linux), these are the same settings. Pick one of the two `ExtensionSettings` shapes. Force install: ```json { "ExtensionInstallForcelist": [ ";https://clients2.google.com/service/update2/crx" ], "ExtensionSettings": { "": { "installation_mode": "force_installed", "update_url": "https://clients2.google.com/service/update2/crx", "toolbar_pin": "force_pinned" } } } ``` Allow only: ```json { "ExtensionSettings": { "": { "installation_mode": "allowed", "update_url": "https://clients2.google.com/service/update2/crx" } } } ``` The managed storage policy, in the extension's own policy block: ```json { "tenantDomain": "" } ``` The full file with comments is in [Chrome policy JSON](https://docs.applane.dev/reference/chrome-policy/). ## What the extension asks Chrome for So your Chrome policy reviewer can map it: `identity` and `identity.email` (sign in, prefill the domain), `storage` and `unlimitedStorage` (chat history and drafts in the browser), `alarms` (daily licence refresh), and host permissions for `*.googleapis.com`, `script.google.com`, `script.googleusercontent.com` (Google APIs with the user's token, preview of deployed apps) and Applane's API host (tenant config and licence). No remote code; no content scripts. ## Verify Open `chrome://policy` on a managed profile and reload policies. The extension id appears under `ExtensionInstallForcelist` or `ExtensionSettings`. With force install, the icon appears in the toolbar within a few minutes. Then tell the Applane admin. The [setup checklist](https://docs.applane.dev/console/setup-checklist/) has a manual "extension allowed or force-installed" row they tick. --- # Why does Apps Script return 403, and how do I turn on the Apps Script API? > Each builder turns on Google Apps Script API once at script.google.com/home/usersettings. Until then every Apps Script API call for that user returns 403. Source: https://docs.applane.dev/workspace-admins/apps-script-api/ **Who:** Each builder, once. The Workspace admin only needs to know about it. **Time:** 30 seconds per builder Google keeps one Apps Script setting outside the Admin console. Each user has a personal switch called **Google Apps Script API** at [script.google.com/home/usersettings](https://script.google.com/home/usersettings). While it is off, every call to the Apps Script API for that user returns HTTP 403, so the extension cannot create or deploy an app. The extension detects this on first run. It probes the API once, and on the 403 it shows a card with the link. The builder flips the switch, comes back, and the extension re-checks when the tab regains focus. No sign-out is needed. ## Turn it on 1. Open [script.google.com/home/usersettings](https://script.google.com/home/usersettings) with your work account. 2. Set **Google Apps Script API** to **On**. 3. Go back to the extension. ## The org-level question We have found no Admin console setting that turns this on for everyone. The core-service toggle at **Apps > Google Workspace > Apps Script** must be on for the builders' OU (see [Prerequisites](https://docs.applane.dev/workspace-admins/prerequisites/)), but it does not flip the per-user API switch. If your edition has an org-wide default we have not seen, tell us at the support address in the console and we will document it here. ## What to tell builders One line in your rollout message is enough: "The first time you open Applane it will ask you to turn on the Apps Script API at script.google.com/home/usersettings. That is expected; it is a Google setting, and it takes one click." The [Apps Script 403](https://docs.applane.dev/reference/errors/#apps-script-403) entry in the error reference covers the same thing from the builder's side. --- # Does Applane need to be a trusted app in Google Workspace? > Not for the extension: its OAuth client is yours. Only the admin console's Google sign-in may need trusting if API controls block third-party apps. Source: https://docs.applane.dev/workspace-admins/third-party-app-access/ **Who:** Google Workspace admin **Time:** 2 minutes, usually nothing to do Google Workspace lets you restrict which OAuth apps can access your users' data (**Security > Access and data control > API controls**). Applane sits on the easy side of that control. ## The extension: your own app, nothing to trust The OAuth client the extension signs in with belongs to your GCP project. Its consent screen is Internal and carries your own app name. In Google's eyes, an employee granting scopes to it is granting scopes to your company's own app. So there is no Applane app to add to your trusted list for the extension. If your API controls are set to "restricted" for Google services, apps in your own organisation are still allowed, and this one is in your organisation. You can see and revoke the grant per user under **Security > API controls > Manage third-party app access**, where it appears under the app name your GCP admin chose (for example `Applane (Acme)`). Revoking it there signs that user out of the extension; they can sign in again unless you also block the app. ## The admin console: Applane's own sign-in The Applane admin console at `admin.applane.dev` is different. Its "Sign in with Google" uses Applane's own Google client, with the `openid`, `email` and `profile` scopes only. Those scopes are non-sensitive; the client reads the admin's email address and nothing else. If your API controls block unlisted third-party apps from using Google sign-in, an admin will see `access_denied` or `admin_policy_enforced` on the console's sign-in page. Two ways to fix it: 1. **Security > API controls > Manage third-party app access > Configure new app**. Search for the Applane console by name, or add it by its client id (ask support for it if the search does not find it). Mark it **Trusted** for the OU of the people who will administer Applane. It only needs the basic sign-in scopes. 2. Or set Google sign-in to **Allow users to access any third-party app** for that OU alone. The first is the narrower change. The extension is not affected either way; it never uses Applane's client. ## The MCP bridge [Connecting Claude Code or Claude Desktop](https://docs.applane.dev/builders/claude-code/) adds no OAuth client and asks for no extra scopes. The bridge drives the extension's existing token. There is nothing to trust for it. --- # Which accounts and groups does Applane use? > Three Workspace identities: a builders group for the Vertex AI role, an admin group made editor on every published app, and a bot account for public apps. Source: https://docs.applane.dev/workspace-admins/accounts-and-groups/ **Who:** Google Workspace admin **Time:** 5 minutes Create these once in the Google Admin console. Two go into the Applane console; one goes into the GCP IAM grant. | Identity | Type | What it is for | |---|---|---| | `applane-builders@` | Google Group | Who may build. It gets `roles/aiplatform.user` on the GCP project, so joining the group is the whole onboarding for a new builder. People who only open finished apps never need it. | | `applane-admins@` | Google Group | Made editor on every published app by rule. Members see the organisation's app inventory in the extension and can take over or repoint any app. Put IT or the platform team in it. | | `applane-bot@` | User account (needs a Workspace licence) | Publishes partner-facing and public apps, so those apps run as the bot rather than as a person who may leave. Internal-only apps never use it. | The names are conventions, not requirements. Use whatever fits your naming policy and paste the real addresses into the Applane console. ## Create the groups 1. **Directory > Groups > Create group**. 2. Name and email as above. Access type: Team or Restricted; the group needs no external members. 3. Add the first builders to `applane-builders@`. Add IT to `applane-admins@`. Group membership changes reach the GCP IAM grant within a few minutes. ## Create the bot account 1. **Directory > Users > Add new user**. Name it something obvious, for example "Applane bot". 2. Assign a Workspace licence (it needs Drive and Apps Script). 3. Add it to `applane-admins@` so it can edit every published app. 4. Store its credentials the way you store other service logins. It is used from a browser session by whoever publishes external or public apps, not by Applane's backend. Skip this account if you will never allow external or anonymous audiences. The Applane admin can turn those audiences off in [Settings](https://docs.applane.dev/console/settings/). ## Hand over Give the Applane admin the three addresses. They go into the [setup checklist](https://docs.applane.dev/console/setup-checklist/) (bot account, admin group) and the GCP admin uses the builders group in [IAM](https://docs.applane.dev/gcp-admins/iam/). --- # Which Drive sharing settings does Applane need? > Internal apps need nothing. Partner and public apps need external or link sharing allowed for the builders' OU. Applane never changes the policy itself. Source: https://docs.applane.dev/workspace-admins/drive-sharing/ **Who:** Google Workspace admin **Time:** 5 minutes, often nothing to change Applane does not change **Apps > Google Workspace > Drive and Docs > Sharing settings**. It reads your policy and works within it. Each app has one audience, chosen when it is created and fixed after that. | Audience | Who can open the app | What your Drive policy must allow | |---|---|---| | Internal (default) | Anyone signed in at your domain | Nothing extra. Google rejects any non-domain login before the app's code runs. | | External (partner portal) | Named partner accounts outside your domain | External sharing on for the builders' OU, or the partner domains allowlisted. The app is published from the bot account. | | Anonymous (public link) | Anyone with the link, no sign-in | "Anyone with the link" sharing allowed for the publishing OU. The app may only show data that is already public. | If external sharing is off for the builders' OU, the external and anonymous audiences stay disabled in the extension. That is a valid configuration; many companies run internal-only. ## Source collaboration is a Drive ACL An app's source is an Apps Script project, which is a Drive file. Who can edit that file is a Drive permission, set through Google's own share dialog. The extension's Share button opens that dialog; it never grants access itself. So whether a builder can add an external account as an editor of an app's source is decided entirely by your Drive external-sharing policy. Applane neither enables nor restricts it. ## What to set - Internal-only company: leave your policy as it is. Confirm the audiences are limited to internal in the Applane console [Settings](https://docs.applane.dev/console/settings/). - Partner portals: allow external sharing for the OU that holds `applane-bot@` and the builders, or allowlist the partner domains. Keep "warn on external sharing" on if you have it. - Public apps: allow link sharing for the bot's OU. Review the [public-data-only rule](https://docs.applane.dev/builders/sharing/#anonymous-public-link) with the builders. --- # What happens to Applane apps when a builder leaves? > The apps keep running. Transfer the leaver's Drive files, remove them from the builders group, and reclaim the seat in the Applane console. Source: https://docs.applane.dev/workspace-admins/offboarding/ **Who:** Google Workspace admin, with the Applane admin for the seat **Time:** 10 minutes per person Every app a builder made is an Apps Script project in their Drive. Deployed internal apps run as whoever opens them, so they keep working the day the builder leaves. Published external and public apps were deployed from the bot account and keep running too. What you need to do is what you do for any leaver's Drive, plus one click in the Applane console. ## 1. Transfer Drive ownership Before you delete or suspend the account, transfer its Drive files, including the Apps Script projects, to a person or to `applane-bot@`. - Whole account: **Directory > Users > the user > More options > Transfer data** (or the transfer prompt during deletion). Choose Drive and Docs. - One app only: open its project from the extension or from `script.google.com`, use Google's share dialog, and make another editor the owner. `applane-admins@` is already an editor on every published app, so IT can open, repoint or transfer any of them without the leaver. ## 2. Remove them from the builders group Remove the account from `applane-builders@`. This drops their `roles/aiplatform.user` grant on the GCP project, so no more Vertex spend can be attributed to them. ## 3. Reclaim the seat Ask the Applane admin to open **People** in the console and choose **Reclaim seat** on the leaver's row. That frees the seat for someone else immediately. If you skip this, the seat is reclaimed automatically after 60 days without a sign-in, and monthly billing counts active seats only. See [People and seats](https://docs.applane.dev/console/people-and-seats/). Suspending or deleting the Google account also ends the person's sessions: the extension cannot renew a licence without a Google sign-in, and the seat goes idle from that day. ## 4. Revoke the OAuth grant (optional) Suspending the account already invalidates its tokens. If you keep the account active for a hand-over period but want Applane closed for them, revoke the grant under **Security > API controls > Manage third-party app access**, or block the seat in the console. --- # How do I remove Applane? > Remove the Chrome policy, the IAM grant and the OAuth client, cancel the subscription and close the tenant. The apps keep running in your Apps Script. Source: https://docs.applane.dev/workspace-admins/uninstall/ **Who:** Google Workspace admin, GCP admin and Applane admin, one part each **Time:** 20 minutes The apps keep running after Applane is gone. They are Apps Script projects in your Drive, deployed on `script.google.com` under your domain, and nothing about them depends on Applane. Only the builder goes away. ## Workspace admin 1. Remove the extension from the Chrome policy: **Devices > Chrome > Apps & extensions > Users & browsers**, the OU, the extension's row, delete. Force-installed copies disappear at the next policy refresh. 2. Optionally revoke the grant for all users under **Security > API controls > Manage third-party app access**, under your app's name. 3. Keep `applane-admins@` and `applane-bot@` as long as any published external or public app exists; the bot is the deployment owner of those apps. Delete the builders group whenever you like. ## GCP admin Remove the IAM grant. Disable the APIs only if the project is dedicated to Applane; other workloads may use them. ```bash gcloud projects remove-iam-policy-binding \ --member=group:applane-builders@ --role=roles/aiplatform.user # only if the project is dedicated to Applane gcloud services disable script.googleapis.com aiplatform.googleapis.com \ sheets.googleapis.com drive.googleapis.com docs.googleapis.com --project gcloud billing budgets delete --billing-account= ``` Then delete the OAuth client under **APIs & Services > Credentials**. Terraform and Infrastructure Manager users: `terraform destroy` or `gcloud infra-manager deployments delete` removes the grant and the budget and leaves the APIs on; see the [Terraform](https://docs.applane.dev/gcp-admins/setup/terraform/#remove-it) and [Infrastructure Manager](https://docs.applane.dev/gcp-admins/setup/infrastructure-manager/#remove-it) pages. ## Applane admin 1. Cancel the subscription in **Billing** (the Stripe portal). Billing stops at the end of the period. 2. Write to the support address to close the tenant. All tenant rows are deleted within 30 days; Stripe keeps invoices for the legal seven years. See [DPA and sub-processors](https://docs.applane.dev/security/dpa-and-sub-processors/). 3. Remove the `applane-verify` TXT record from your DNS. --- # What does the GCP project need for Applane? > One project inside your Workspace organisation, with billing linked and owner or editor rights. Vertex AI needs billing; an existing project is fine. Source: https://docs.applane.dev/gcp-admins/prerequisites/ **Who:** GCP admin: owner or editor on the project **Time:** 5 minutes to check Applane calls Google APIs from the employee's browser with the employee's own token. Google checks API enablement on the project that owns the OAuth client, and bills Vertex AI to that project. So you need one project, with three properties. | Property | Why | How to check | |---|---|---| | It sits inside your Google Workspace organisation | The OAuth consent screen can only be Internal for a project that belongs to an organisation. Internal is what removes Google's app verification. | `gcloud projects describe --format='value(parent.type,parent.id)'` prints `organization` or `folder`. A project with no parent must be moved or replaced. | | Billing is linked | Vertex AI refuses every request on a project without a billing account, even inside the free tier. | `gcloud billing projects describe --format='value(billingEnabled)'` prints `True`. | | You are owner or editor | Enabling APIs and granting IAM need `serviceusage.services.enable` and `resourcemanager.projects.setIamPolicy`. | `gcloud projects get-iam-policy --flatten=bindings --filter="bindings.members:$(gcloud config get-value account)" --format='value(bindings.role)'` | An existing project is fine. The setup tools only add what is missing: five APIs, one IAM grant, an optional budget alert. Nothing is deleted or changed. If a platform team already runs Vertex AI in a project, that project is the natural choice. ## What it costs Google bills Gemini tokens to this project at list price. Applane adds no AI usage fee and never sees the bill. In our own testing, a full day of building used $0.59 of Gemini tokens; that is the only number we have measured. Your usage depends on how many builders you have and how much they build. The [budget alert](https://docs.applane.dev/gcp-admins/budget-alerts/) is the control; the default it creates is 50 in the billing account's currency per month, with alerts at 50%, 90% and 100%. Apps Script, Sheets, Drive and Docs have no per-call charge for Workspace users. What Vertex AI bills, and how the extension's context caching cuts it, is on [Model cost](https://docs.applane.dev/gcp-admins/model-cost/). ## What you will create | Resource | What | |---|---| | Five enabled APIs | `script`, `aiplatform`, `sheets`, `drive`, `docs` (`.googleapis.com`). [The five APIs](https://docs.applane.dev/gcp-admins/apis/) | | One IAM binding | `roles/aiplatform.user` to the builders group. [IAM](https://docs.applane.dev/gcp-admins/iam/) | | One budget (optional) | Alerts only; nothing is cut off. [Budget alerts](https://docs.applane.dev/gcp-admins/budget-alerts/) | | One consent screen | Internal, your own app name. [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) | | One OAuth client | Web application, two redirect URIs. [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) | No service accounts, no keys, no buckets, no queues. Start with [Set up the project](https://docs.applane.dev/gcp-admins/setup/). --- # Do I need Google app verification for Applane? > No. The OAuth client is yours and its consent screen is Internal, which Google exempts from verification and CASA. Applane owns no client with your data. Source: https://docs.applane.dev/gcp-admins/no-verification-needed/ The OAuth client the extension signs in with is yours: it lives in your GCP project and its consent screen is set to Internal. Google exempts Internal apps from app verification and from the "unverified app" warning, whatever scopes they use. Applane owns no Google client that touches your data, so there is no Applane app in Google's verification queue and no CASA assessment to renew. The rest of this page is the detail for a security reviewer. ## What "Internal" changes An OAuth consent screen has a user type. **External** apps can be used by any Google account and must pass Google's app verification before they can request sensitive scopes; restricted scopes also need a CASA security assessment by a Google-authorised lab, every year. **Internal** apps can only be used by accounts in the project's own Workspace organisation, and Google skips all of that: no review, no assessment, no warning screen, any scope. Internal is only available when the project belongs to a Workspace organisation, which is exactly your situation. See [Prerequisites](https://docs.applane.dev/gcp-admins/prerequisites/). ## What the extension requests The extension asks for three sensitive scopes and one restricted one (`drive.readonly`), plus sign-in. Each is explained in the [Scopes reference](https://docs.applane.dev/security/scopes/). All of them are granted to your client, under your app name. Your Workspace admin can see and revoke the grant per user in the Admin console under that name. ## The one Google client Applane owns The Applane admin console signs admins in with Applane's own Google client. It uses `openid`, `email` and `profile`, which are non-sensitive scopes that need no verification. It reads the admin's email address and nothing else. See [Third-party app access](https://docs.applane.dev/workspace-admins/third-party-app-access/) if your API controls block it. ## For the security questionnaire When asked "have you completed Google's restricted scope verification", the accurate answer is: "Not applicable. Each customer's OAuth client is Internal to their own organisation, which Google exempts from verification and CASA. Applane holds no Google client with access to customer data." --- # How do I set up the GCP project for Applane? > Four ways to prepare the project: Cloud Shell, Infrastructure Manager, Terraform or a script. Each enables five APIs, grants one role, adds a budget alert. Source: https://docs.applane.dev/gcp-admins/setup/ **Who:** GCP admin **Time:** 10 minutes with any option Every option enables the five APIs, grants `roles/aiplatform.user` to the builders group, and optionally creates a budget alert. All are add-only: nothing existing is changed or removed, and running one twice is safe. | Option | Pick it when | Needs | |---|---|---| | [Open in Cloud Shell](https://docs.applane.dev/gcp-admins/setup/cloud-shell/) | You want a one-off by hand with nothing installed. A guided panel in your browser. | A browser and project rights. | | [Infrastructure Manager](https://docs.applane.dev/gcp-admins/setup/infrastructure-manager/) | The project should be Terraform-managed but nobody wants to run Terraform from a laptop. Google runs it and keeps the state. | `gcloud`, `roles/config.admin`. | | [Terraform](https://docs.applane.dev/gcp-admins/setup/terraform/) | The project's APIs and IAM already live in your own Terraform. A resource created by hand shows up as drift on the next plan. | Terraform 1.15+, provider `hashicorp/google` 6.x. | | [Script](https://docs.applane.dev/gcp-admins/setup/script/) | `gcloud` is already signed in as an owner or editor. Prints every command before running it; `--dry-run` first. | `gcloud` 400+, bash 3.2+. | Two steps stay manual whatever you pick, because Google has no API for them: the [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) and the [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). They take five minutes in the Cloud console, and every option prints the instructions when it finishes. Before you start, have these values ready: | Value | Where it comes from | |---|---| | `` | The project. See [Prerequisites](https://docs.applane.dev/gcp-admins/prerequisites/). | | `applane-builders@` | The builders group. The Workspace admin creates it: [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/). | | `` | Shown in the Applane console under Setup. Only used to print the redirect URI. | | `` | Optional, for the budget alert. `gcloud billing projects describe --format='value(billingAccountName)'` | --- # Open in Cloud Shell > A guided Cloud Shell walkthrough that picks the project, enables the five APIs, runs applane-setup.sh and links the two console steps. Nothing to install. Source: https://docs.applane.dev/gcp-admins/setup/cloud-shell/ **Who:** GCP admin **Time:** 10 minutes Cloud Shell is a terminal Google runs in your browser, already signed in as you, with `gcloud` installed. The walkthrough opens the Applane setup repository in it and shows a step panel on the side. Pick this when you want a one-off by hand and nothing installed on your machine. ## Open it Click the button. It clones the setup repository into your Cloud Shell and opens the tutorial panel. [![Open in Cloud Shell](https://gstatic.com/cloudssh/images/open-btn.svg)](https://shell.cloud.google.com/cloudshell/open?cloudshell_git_repo=&cloudshell_tutorial=infra/cloudshell/tutorial.md&cloudshell_workspace=infra) The link with the repository filled in is on the Applane console's Setup page. ## What the panel walks you through 1. **Pick the project.** A project picker with a billing check. An existing project is fine. Set it as active in the terminal: ```bash gcloud config set project export GOOGLE_CLOUD_PROJECT= ``` 2. **Enable the five APIs.** A button in the panel, or let the script do it in the next step. Both enable the same five. 3. **Run the setup script.** Preview first, then apply: ```bash GROUP=applane-builders@ scripts/applane-setup.sh --dry-run --project $GOOGLE_CLOUD_PROJECT --group $GROUP scripts/applane-setup.sh --project $GOOGLE_CLOUD_PROJECT --group $GROUP ``` With a budget alert: ```bash gcloud billing projects describe $GOOGLE_CLOUD_PROJECT --format='value(billingAccountName)' scripts/applane-setup.sh --project $GOOGLE_CLOUD_PROJECT --group $GROUP \ --budget-account --budget-amount 50 ``` 4. **Consent screen and OAuth client.** The panel opens APIs & Services for you. Follow [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) and [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). 5. **Check the result.** ```bash scripts/applane-setup.sh --check --project $GOOGLE_CLOUD_PROJECT --group $GROUP ``` Every line should read `PASS`. The two `INFO` lines (the per-user Apps Script API setting and the OAuth client) are verified by the [setup checker in the Applane console](https://docs.applane.dev/console/setup-checklist/) instead. ## What it creates The same three things as every option: the five APIs enabled, `roles/aiplatform.user` on the builders group, and a budget alert if you passed a billing account. See [Script](https://docs.applane.dev/gcp-admins/setup/script/) for the exact commands the script runs. ## Remove it Cloud Shell keeps no state. To undo, follow the GCP part of [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/#gcp-admin). --- # Infrastructure Manager > Google's managed Terraform runs the Applane module from git and keeps the state in your project. Needs one service account and roles/config.admin. Source: https://docs.applane.dev/gcp-admins/setup/infrastructure-manager/ **Who:** GCP admin with roles/config.admin on the project **Time:** 15 minutes the first time Infrastructure Manager runs the Applane Terraform module for you. State lives in a Cloud Storage bucket it creates in your project, and every revision is visible in the Cloud console under **Infrastructure Manager**. Pick this when the project should be managed as code but nobody wants Terraform on a laptop. ## One-time setup Infra Manager acts as a service account, which needs the rights to create what the module creates. Your own account needs `roles/config.admin` on the project. ```bash gcloud services enable config.googleapis.com --project gcloud iam service-accounts create applane-infra-manager --project SA=applane-infra-manager@.iam.gserviceaccount.com for role in roles/config.agent roles/serviceusage.serviceUsageAdmin \ roles/resourcemanager.projectIamAdmin; do gcloud projects add-iam-policy-binding \ --member=serviceAccount:$SA --role=$role --condition=None done # only if you pass billing_account_id (budget alert): gcloud billing accounts add-iam-policy-binding \ --member=serviceAccount:$SA --role=roles/billing.costsManager ``` | Role | Why | |---|---| | `roles/config.agent` | Lets Infra Manager run Terraform as this account. | | `roles/serviceusage.serviceUsageAdmin` | Enable the five APIs. | | `roles/resourcemanager.projectIamAdmin` | The Vertex grant to the builders group. | | `roles/billing.costsManager` on the billing account | The budget alert, only when one is requested. | This service account is Infra Manager's, not Applane's. Applane never has access to it or to your project. ## Apply ```bash gcloud infra-manager deployments apply projects//locations/europe-west1/deployments/applane \ --service-account=projects//serviceAccounts/$SA \ --git-source-repo= \ --git-source-directory=infra/terraform/customer-gcp \ --git-source-ref=main \ --input-values=project_id=,builders_group_email=applane-builders@,billing_account_id=,applane_extension_id= ``` Leave `billing_account_id` out of `--input-values` to skip the budget. `europe-west1` is the default location; any Infra Manager region works. If the repository is not reachable from Google, clone it and pass `--local-source=infra/terraform/customer-gcp` instead of the three `--git-source-*` flags. ## What it creates The [Terraform module](https://docs.applane.dev/reference/terraform-module/): five `google_project_service` resources, one `google_project_iam_member`, and one `google_billing_budget` when a billing account is set. ## Verify ```bash DEPLOYMENT=projects//locations/europe-west1/deployments/applane gcloud infra-manager deployments describe $DEPLOYMENT gcloud infra-manager revisions list --deployment=$DEPLOYMENT # outputs (redirect URIs, console steps) sit under applyResults.outputs of the latest revision: gcloud infra-manager revisions describe $DEPLOYMENT/revisions/r-0 --format='yaml(applyResults.outputs)' ``` The deployment state should read `ACTIVE`. The `consent_screen_instructions` output tells you what to do next: the [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) and [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). Then run the [setup checker](https://docs.applane.dev/gcp-admins/verify/). ## Remove it ```bash gcloud infra-manager deployments delete $DEPLOYMENT ``` This removes the IAM grant and the budget. The APIs stay on (`disable_on_destroy = false` in the module), because other workloads may use them. Disable them by hand if the project is dedicated to Applane; see [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/#gcp-admin). --- # Terraform > Add the customer-gcp module to your own Terraform: five APIs, one IAM binding and an optional budget. Verified with Terraform 1.15 and google 6.50. Source: https://docs.applane.dev/gcp-admins/setup/terraform/ **Who:** GCP admin who runs Terraform for the project **Time:** 10 minutes Pick this when the project's IAM and APIs already live in your Terraform. A resource created by hand shows up as drift on the next plan; adding the module keeps the plan clean. Verified with Terraform 1.15 and `hashicorp/google` 6.50. ## Add the module ```hcl module "applane" { source = "github.com//applane//infra/terraform/customer-gcp" project_id = "" builders_group_email = "applane-builders@" applane_extension_id = "" # optional: budget alert at 50%, 90%, 100% of budget_amount per month billing_account_id = "" budget_amount = 50 } output "applane_next_steps" { value = module.applane.consent_screen_instructions } ``` The module source with the organisation filled in is on the Applane console's Setup page. Inputs and outputs are listed in the [Terraform module reference](https://docs.applane.dev/reference/terraform-module/). If another module already manages `google_project_service` on this project, set `enable_apis = false` and enable the [five APIs](https://docs.applane.dev/gcp-admins/apis/) there instead. Two Terraform resources for the same API fight each other. ## Or run the example on its own ```bash git clone applane && cd applane/infra/terraform/customer-gcp cp examples/basic/terraform.tfvars.example examples/basic/terraform.tfvars # fill in project, group, extension id cd examples/basic gcloud auth application-default login terraform init terraform plan terraform apply terraform output consent_screen_instructions ``` ## Creating the project too The module never creates projects. If you want one config to do both, add a `google_project` in your root module and pass `existing_project = false` so the module's billing check is skipped at plan time: ```hcl resource "google_project" "applane" { name = "Applane" project_id = "acme-applane" org_id = var.org_id # or folder_id billing_account = var.billing_account_id } module "applane" { source = "github.com//applane//infra/terraform/customer-gcp" project_id = google_project.applane.project_id builders_group_email = "applane-builders@acme.com" billing_account_id = var.billing_account_id existing_project = false } ``` ## What it creates | Resource | What | Why | |---|---|---| | `google_project_service` x5 | `script`, `aiplatform`, `sheets`, `drive`, `docs` `.googleapis.com` | Google checks API enablement on the project that owns the OAuth client. `disable_on_destroy = false`: destroying the module never switches an API off. | | `google_project_iam_member` | `roles/aiplatform.user` to `group:` | Lets builders call Gemini on Vertex AI. No service accounts, no keys. | | `google_billing_budget` | 50%, 90%, 100% of `budget_amount` per month | Only when `billing_account_id` is set. Alerts go to the billing admins; nothing is cut off. Also enables `billingbudgets.googleapis.com`. | A `data "google_project"` read checks that billing is linked and fails the plan with a clear message if it is not. ## Why the consent screen and the client are not in Terraform Google has no API for the OAuth consent screen or for a standard OAuth 2.0 client. The provider's `google_iap_client` and `google_iap_brand` only create clients for Identity-Aware Proxy, and an IAP client does not work with the extension's sign-in flow. So two steps stay in the console: [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) and [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). The module prints them in `consent_screen_instructions`. ## Verify `terraform plan` after apply shows no changes. Then run the [setup checker](https://docs.applane.dev/gcp-admins/verify/). ## Remove it `terraform destroy` removes the IAM binding and the budget. The five APIs stay enabled on purpose; disable them by hand if the project is dedicated to Applane, then delete the OAuth client in the console. See [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/#gcp-admin). --- # Script > applane-setup.sh enables the five APIs, grants roles/aiplatform.user to your builders group and adds a budget alert. Add-only, with --dry-run and --check. Source: https://docs.applane.dev/gcp-admins/setup/script/ **Who:** GCP admin with gcloud signed in as owner or editor **Time:** 5 minutes `applane-setup.sh` is a bash script. It is add-only, prints every command before running it, and supports `--dry-run`. Nothing is deleted. It works with bash 3.2 (the macOS default) and `gcloud` 400 or newer. Pick this when `gcloud` is already signed in and you want to see each command. ## Get it The Applane console generates the command below with your values filled in (**Setup > Google Cloud project > Download applane-setup.sh**). Or fetch it from the repository: ```bash curl -fsSLO /raw/main/infra/scripts/applane-setup.sh chmod +x applane-setup.sh ``` ## Preview, then apply ```bash ./applane-setup.sh --dry-run \ --project \ --group applane-builders@ \ --budget-account \ --budget-amount 50 \ --extension-id ``` `--dry-run` prints every command without running anything. Run the same line without the flag to apply. Leave out `--budget-account` if finance manages budgets elsewhere. All flags are listed in the [script reference](https://docs.applane.dev/reference/setup-script/). ## What it runs ```bash gcloud config set project gcloud services enable \ script.googleapis.com \ aiplatform.googleapis.com \ sheets.googleapis.com \ drive.googleapis.com \ docs.googleapis.com gcloud projects add-iam-policy-binding \ --member=group:applane-builders@ --role=roles/aiplatform.user # only with --budget-account gcloud services enable billingbudgets.googleapis.com gcloud billing budgets create --billing-account= \ --display-name=applane-vertex- --budget-amount=50 \ --filter-projects=projects/ \ --threshold-rule=percent=0.5 --threshold-rule=percent=0.9 --threshold-rule=percent=1.0 ``` When it finishes it prints the two console steps and the redirect URIs for the client: [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/), [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). ## Verify ```bash ./applane-setup.sh --check --project --group applane-builders@ ``` Every line reads `PASS`. Two lines read `INFO` because the script cannot see them: the per-user Apps Script API setting and the OAuth client. The [setup checker in the console](https://docs.applane.dev/console/setup-checklist/) verifies those. More in [Verify your setup](https://docs.applane.dev/gcp-admins/verify/). ## Remove it The script has no remove mode on purpose. The commands are in [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/#gcp-admin). --- # Which Google APIs does Applane need? > Five: Apps Script, Vertex AI, Sheets, Drive and Docs. Google checks API enablement on the project that owns the OAuth client, so all five go on there. Source: https://docs.applane.dev/gcp-admins/apis/ The extension calls five Google APIs with the builder's own token. Google checks API enablement on the project that owns the OAuth client, so all five must be on in your project. That is the full list; Applane needs no others. | API | What the extension uses it for | |---|---| | `script.googleapis.com` | Create each app's Apps Script project, push its files, create and update the web-app deployment that gives it a URL, read execution history. | | `aiplatform.googleapis.com` | Call Gemini on Vertex AI as the builder. Billed to this project. | | `sheets.googleapis.com` | Read sheet schemas while building. Read-write apps write to sheets as the signed-in viewer. | | `drive.googleapis.com` | List the apps shared with a builder and read the docs, slides and folders they point the agent at. Never writes. | | `docs.googleapis.com` | Read Google Docs used as context for a build. | Every [setup option](https://docs.applane.dev/gcp-admins/setup/) enables them. By hand: ```bash gcloud services enable \ script.googleapis.com \ aiplatform.googleapis.com \ sheets.googleapis.com \ drive.googleapis.com \ docs.googleapis.com \ --project ``` Enabling an API that is already on is a no-op. Check: ```bash gcloud services list --enabled --project \ --filter='config.name:(script OR aiplatform OR sheets OR drive OR docs)' \ --format='value(config.name)' ``` Five lines back means done. The budget alert adds a sixth, `billingbudgets.googleapis.com`, which only the budget uses. --- # Which IAM role do Applane builders need? > One: roles/aiplatform.user on the project, granted to the builders Google Group. No service accounts, no keys, no other bindings. Source: https://docs.applane.dev/gcp-admins/iam/ **Who:** GCP admin **Time:** 2 minutes Builders call Vertex AI with their own Google account. For that, each of them needs `roles/aiplatform.user` on the project. Grant it once to the builders group, and from then on adding a builder means adding them to the group. ```bash gcloud projects add-iam-policy-binding \ --member=group:applane-builders@ \ --role=roles/aiplatform.user ``` Group membership changes reach IAM within a few minutes. The group is created by the Workspace admin: [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/). ## No service accounts, anywhere Applane creates no service account, no key, and no other IAM binding. There is nothing for Applane to hold, because every call is made from the builder's browser with the builder's own token. If a security review asks what Applane can do in your project, the answer is: nothing; it has no identity there. The only exception is [Infrastructure Manager](https://docs.applane.dev/gcp-admins/setup/infrastructure-manager/), which needs its own service account to run Terraform. That account is Google's deployment runner, not Applane's. ## What `roles/aiplatform.user` allows Calling models, reading model metadata, and using Vertex AI endpoints in this project. It does not allow reading other projects, creating resources, or changing IAM. A builder's token is only as powerful as the builder's own IAM, so for a typical employee this role is the only GCP right they hold. ## Context caching permissions The extension keeps its system prompt in a Vertex AI context cache during a build turn instead of re-sending it every round, which is where most of the saving on [model cost](https://docs.applane.dev/gcp-admins/model-cost/) comes from. That needs four permissions on the project: ```text aiplatform.cachedContents.create aiplatform.cachedContents.get aiplatform.cachedContents.list aiplatform.cachedContents.delete ``` `roles/aiplatform.user` already includes all four, so the grant above is enough. If your company grants a custom role instead, add those four plus `aiplatform.endpoints.predict`, which the model call itself needs. Without them the extension still works. Every turn is then billed at the full input rate, and the Costs panel in the extension shows "Context cache: off". ## Verify ```bash gcloud projects get-iam-policy \ --flatten=bindings --filter='bindings.role=roles/aiplatform.user' \ --format='value(bindings.members)' ``` Expect `group:applane-builders@` in the output. The [setup checker](https://docs.applane.dev/gcp-admins/verify/) tests the same binding. --- # How do I set up the OAuth consent screen for Applane? > User type Internal, your own app name, your IT address as contact, no scopes added. Internal removes Google's verification and the unverified-app warning. Source: https://docs.applane.dev/gcp-admins/oauth-consent-screen/ **Who:** GCP admin **Time:** 3 minutes Google has no API for this screen, so it is done in the Cloud console. Open **APIs & Services > OAuth consent screen**. On newer consoles it is **Google Auth Platform > Branding** and **Audience**. | Field | Value | |---|---| | User type (Audience) | **Internal**. Only accounts in your Workspace organisation can sign in. This is what removes Google's verification and the "unverified app" warning. See [No Google app verification needed](https://docs.applane.dev/gcp-admins/no-verification-needed/). | | App name | `Applane ()`. Employees see it on the consent screen and in their third-party access list; your Workspace admin sees it under the same name. | | User support email | Your IT or helpdesk address. | | Developer contact | The same address. | | App logo | Optional. A logo on an Internal app triggers no review. | | Authorised domains | Leave empty. Not needed for Internal apps. | | Scopes | Add none. The extension requests its scopes at sign-in; Internal apps may use any scope. | Save. If the console offers a "Publishing status", Internal apps have none; there is nothing to publish. ## The scopes the extension will request You do not add them here, but you will see them on the consent screen at first sign-in, under your app name. | Scope | Google's class | Why | |---|---|---| | `openid`, `email` | non-sensitive | Sign the employee in and check the account belongs to your domain. Any other account is rejected. | | `https://www.googleapis.com/auth/script.projects` | sensitive | Create each app's Apps Script project and push its files. | | `https://www.googleapis.com/auth/script.deployments` | sensitive | Create and update the web-app deployment that gives each app its URL. | | `https://www.googleapis.com/auth/script.processes` | sensitive | Read execution history, so a builder is told when a scheduled run failed. | | `https://www.googleapis.com/auth/spreadsheets` | sensitive | Read sheet schemas while building; read-write apps write to sheets as the viewer. | | `https://www.googleapis.com/auth/drive.readonly` | restricted | List the apps shared with a builder and read the files they point the agent at. Never writes. | | `https://www.googleapis.com/auth/cloud-platform` | sensitive | Call Vertex AI in your project as the builder, so usage is billed to you. A token is only as powerful as the builder's own IAM. | More on each in the [Scopes reference](https://docs.applane.dev/security/scopes/). The `cloud-platform` scope is the one reviewers ask about; the answer is in [Where things are stored](https://docs.applane.dev/security/where-things-are-stored/) and the security page. ## If a builder sees `access_denied` The consent screen is not Internal, or the account is outside your organisation. Check the user type here, and that the builder used a work account. Full table in [Error messages](https://docs.applane.dev/reference/errors/). Next: [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). --- # How do I create the OAuth client for Applane? > A Web application client with two redirect URIs: the extension's chromiumapp.org URL and the console's oauth-probe. No JavaScript origins, no secret. Source: https://docs.applane.dev/gcp-admins/oauth-client/ **Who:** GCP admin **Time:** 3 minutes Open **APIs & Services > Credentials > Create credentials > OAuth client ID**. | Field | Value | |---|---| | Application type | **Web application**. Not "Chrome extension": that type only works with Chrome's `getAuthToken`, while Applane uses `launchWebAuthFlow`, which also works in Edge and Brave. | | Name | `Applane extension` | | Authorised JavaScript origins | Leave empty. | | Authorised redirect URIs | Exactly two, below. | The two redirect URIs: ```text https://.chromiumapp.org/ https://admin.applane.dev/oauth-probe ``` The first is where the extension's sign-in returns. It is built from the extension's fixed id, so it is the same for every customer. Keep the trailing slash. The second is where the Applane console's **Test sign-in** button returns. That test runs the sign-in flow once with `openid email` only, from the admin's browser, and names the exact Google error if there is one. The token never leaves the browser. Copy both from the Applane console's Setup page rather than typing them. Add nothing else. Click **Create** and copy the **Client ID** (it ends in `.apps.googleusercontent.com`). The client secret is not used: the extension signs in with the implicit flow, which has no secret. ## Paste it into the Applane console **Setup > OAuth consent screen and client > Client id**, then **Test sign-in**. A green "Signed in as you@yourdomain. Consent screen and client work." means both steps are done. See [Setup checklist](https://docs.applane.dev/console/setup-checklist/). ## If you rotate or delete the client Every employee's next sign-in fails with `invalid_client`. Create the new client the same way, paste the new id into the console, and builders pick it up at their next sign-in. Do not delete the old one until the new id is saved. ## If sign-in fails | Error on the Google page | Cause | Fix | |---|---|---| | `redirect_uri_mismatch` | A URI is missing or differs (trailing slash, `http`, a typo in the id). | Paste both URIs exactly as the console shows them; retry after a minute. | | `invalid_client` | Wrong client id in the Applane console, or the client was deleted. | Copy the Client ID again; check for a trailing space. | | `access_denied` | Consent screen not Internal, account outside your organisation, or the app is blocked by a Workspace admin. | Set the user type to Internal; use a work account; ask the Workspace admin to check API controls. | | `admin_policy_enforced` | Third-party apps are restricted to a trusted list. | Workspace admin: [Third-party app access](https://docs.applane.dev/workspace-admins/third-party-app-access/). | | `org_internal` | A personal or external Google account. | Expected. Use a work account. | The same table with the builder-side errors is in [Error messages](https://docs.applane.dev/reference/errors/). --- # How do I set a budget alert for Vertex AI spend? > Create a budget on the billing account with alerts at 50%, 90% and 100% of a monthly amount. The default is 50; alerts only, nothing is cut off. Source: https://docs.applane.dev/gcp-admins/budget-alerts/ **Who:** GCP admin, or a billing admin **Time:** 2 minutes Gemini tokens are billed to your project at Google's list price. A budget alert is the control. It sends email to the billing admins at 50%, 90% and 100% of a monthly amount. It never cuts anything off. Every [setup option](https://docs.applane.dev/gcp-admins/setup/) creates one when you pass a billing account. The default amount is 50 in the billing account's currency (EUR or USD for most accounts). For scale: a full day of building in our own testing used $0.59 of tokens. ## Find the billing account ```bash gcloud billing projects describe --format='value(billingAccountName)' ``` The value looks like `billingAccounts/XXXXXX-XXXXXX-XXXXXX`; the part after the slash is ``. ## Create it by hand ```bash gcloud services enable billingbudgets.googleapis.com --project gcloud billing budgets create --billing-account= \ --display-name=applane-vertex- \ --budget-amount=50 \ --filter-projects=projects/ \ --threshold-rule=percent=0.5 --threshold-rule=percent=0.9 --threshold-rule=percent=1.0 ``` Creating a budget needs `roles/billing.costsManager` on the billing account, which project owners do not always have. If the command is refused, ask a billing admin to run it or to create the budget in the console under **Billing > Budgets & alerts**. ## Skip it Leave out `--budget-account` (script) or `billing_account_id` (Terraform, Infrastructure Manager) if finance manages budgets elsewhere. Everything else works the same. ## Remove it ```bash gcloud billing budgets list --billing-account= gcloud billing budgets delete --billing-account= ``` --- # What does Applane cost on Vertex AI? > Google bills Gemini tokens to your project at list price; Applane adds no fee. A full build day measured $0.59 uncached; context caching cuts most turns. Source: https://docs.applane.dev/gcp-admins/model-cost/ Every model call Applane makes runs on Vertex AI in your own GCP project, with the builder's own account. Google bills your project at its list price for the model in use. Applane never meters, marks up or sees those calls: no prompt and no model output ever reaches Applane. ## What is billed | Item | What it is | How it is priced | |---|---|---| | Input tokens | The system prompt, the tool declarations and the conversation so far, sent on every round of a build turn. | Per million tokens, at the model's input rate. | | Output tokens | What the model writes back: code, tool calls, explanations. | Per million tokens, at the model's output rate, which is higher than input. | | Cached input tokens | The part of the input served from a context cache instead of being re-sent. | About 10% of the input rate. | | Cache storage | Holding a context cache in Vertex AI. | Per million tokens per hour, for as long as the cache exists. | Apps Script, Sheets, Drive and Docs calls have no per-call charge for Workspace users. ## The measured number In our own testing, a full day of building used $0.59 of Gemini tokens, with no caching. Your usage depends on how many builders you have and how much they build. The [budget alert](https://docs.applane.dev/gcp-admins/budget-alerts/) is the control. ## Context caching A build turn is a loop: the model reads, calls a tool, reads the result, and repeats until the app is done. The system prompt and the tool declarations are identical on every round, and they are most of the input. Re-sending them each round is what makes a long turn expensive. The extension avoids that with Vertex AI explicit context caching (`cachedContents`). At the start of a turn it stores the system prompt and tool declarations in a cache, then references that cache on every following round. Each round pays the cached rate for that part instead of the full input rate. Measured on our build benchmark, this cuts the model cost of a build turn by 79 to 90%; the exact saving depends on how many rounds the turn takes. | | | |---|---| | Where the cache lives | In your project, in Vertex AI's `global` location. Vertex serves context caches only from `global`, even for requests routed to `eu`, so the cached system prompt (the app's source, the sheet structure, the tool declarations) sits in a global Vertex resource for up to one hour. It never leaves your project. | | What it holds | The system prompt and tool declarations for that turn. No sheet data, no app source beyond what the turn already sends. | | How long it lives | The cache has a one-hour time to live. The extension deletes it when the turn ends, so storage is billed for minutes, not hours. | | Who can read it | Only the builder who created it, through the same IAM the model call uses. | Caching changes nothing about what the model sees or answers. It only changes how the input is billed. ### Turning it off If a global cache does not fit your data-residency rules, the Applane admin can turn **Context caching** off under [Settings > Features](https://docs.applane.dev/console/settings/#features). Every request then stays in the model's region and is billed at the full input rate, and the Costs panel shows "Context cache: off — disabled for this company". An EU-resident alternative exists at a price: `gemini-3.5-flash` in `europe-west3` caches normally, at about twice the input rate of the default model. ### What it needs The four `aiplatform.cachedContents.create`, `get`, `list` and `delete` permissions, which `roles/aiplatform.user` already includes. Companies that grant a custom role instead must add them, plus `aiplatform.endpoints.predict`. Details on the [IAM page](https://docs.applane.dev/gcp-admins/iam/#context-caching-permissions). Without them the extension still works: every turn is billed uncached, and the Costs panel in the extension shows "Context cache: off". ## Keeping the bill predictable - Grant `roles/aiplatform.user` to the builders group, not to everyone, so only builders can generate Vertex spend. [IAM](https://docs.applane.dev/gcp-admins/iam/) - Set a [budget alert](https://docs.applane.dev/gcp-admins/budget-alerts/) on the project. - Limit the models builders may pick under [Settings](https://docs.applane.dev/console/settings/#llm) in the Applane console. - Read the per-user cost in Cloud Billing reports; every call is attributed to the builder's own account. --- # How do I verify the Applane GCP setup? > Run applane-setup.sh --check for the APIs, IAM and billing, then Run checks in the Applane console for the domain, OAuth client and Apps Script API. Source: https://docs.applane.dev/gcp-admins/verify/ **Who:** GCP admin for the terminal check; the Applane admin for the console check **Time:** 3 minutes ## From the terminal ```bash ./applane-setup.sh --check --project --group applane-builders@ ``` It checks what `gcloud` can see and changes nothing: | Line | What it checks | |---|---| | `PASS API enabled: ...` x5 | Each of the [five APIs](https://docs.applane.dev/gcp-admins/apis/) is on. | | `PASS IAM: roles/aiplatform.user -> group:...` | The [IAM grant](https://docs.applane.dev/gcp-admins/iam/) exists. | | `PASS Billing linked to ...` | The project has a billing account. | | `INFO Apps Script API user setting` | Cannot be checked from here; per user. | | `INFO OAuth consent screen and client` | Cannot be checked from here; Google has no API for it. | A `FAIL` line prints the command that fixes it. ## From the Applane console The Applane admin opens **Setup > Run checks**. The checker runs from their browser and from Applane's backend, each checking what it can see, and stores only pass or fail. | Check | How | If it fails | |---|---|---| | Domain verified | DNS TXT lookup | The record to add. [Verify your domain](https://docs.applane.dev/console/verify-domain/) | | Client id saved | The tenant record | Paste it. [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) | | Test sign-in passed | The sign-in flow once, from the admin's browser, `openid email` only, returning to `https://admin.applane.dev/oauth-probe` | The Google error, verbatim. [Error messages](https://docs.applane.dev/reference/errors/) | | Five APIs enabled | Asks Google which services are on, with the admin's token from that one sign-in | The missing API and the `gcloud services enable` line | | `roles/aiplatform.user` granted | Tests the binding with the admin's token | The `gcloud projects add-iam-policy-binding` line | | Apps Script API reachable | A probe call | The per-user setting link. [Apps Script API](https://docs.applane.dev/workspace-admins/apps-script-api/) | | Extension allowed or force-installed | Manual: the Workspace admin ticks it | [Chrome extension policy](https://docs.applane.dev/workspace-admins/chrome-extension-policy/) | | Bot account and admin group exist | Manual: the Workspace admin ticks it | [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/) | The admin's Google token from the test sign-in is used inside their browser session and is not sent to Applane. ## The real test Install the extension, sign in, and build one app. If your seat appears under **People** in the console and the app opens at its `script.google.com` URL, everything is set up. [Install and sign in](https://docs.applane.dev/builders/install-and-sign-in/), [Your first app](https://docs.applane.dev/builders/first-app/). --- # How do I sign up for Applane? > Sign in at admin.applane.dev with a Google work account and name the company. That starts a 14-day trial for up to 10 builders, with no card. Source: https://docs.applane.dev/console/sign-up/ **Who:** Whoever is setting Applane up for the company. This person becomes the owner. **Time:** 2 minutes The Applane console is at `https://admin.applane.dev`. It is where the company's setup, people, billing and settings live. ## Sign in 1. Open `https://admin.applane.dev/signin`. 2. Click **Sign in with Google** and pick your work account. Personal accounts (`gmail.com`, `outlook.com` and the like) are refused: a company is tied to a Workspace domain, and the domain is read from your sign-in address. If your Workspace admin restricts third-party sign-in you may see `access_denied`; the fix is on [Third-party app access](https://docs.applane.dev/workspace-admins/third-party-app-access/). ## Create the company Shown once, when your domain has no Applane account yet. | Field | What to enter | |---|---| | Company name | Prefilled from your domain. 2 to 80 characters. | | Domain | Read-only, from your sign-in address. Every admin and every builder must be at this domain. | Click **Create company**. This starts a 14-day trial for up to 10 builders. No card is asked for; nothing is charged until you subscribe. See [Billing](https://docs.applane.dev/console/billing/). If you see "`yourdomain` already has an Applane account", someone at your company already signed up. Ask them to invite you as an admin from **People**, or write to support. ## Then You land on **Setup**, a checklist that stays the home screen until every step passes. Start with [Verify your domain](https://docs.applane.dev/console/verify-domain/) because DNS is the slowest step; the rest can happen while it propagates. The full list is on [Setup checklist](https://docs.applane.dev/console/setup-checklist/). A trial-started email goes to your address with the trial end date and a link back to Setup. --- # How do I verify my domain in Applane? > Add one TXT record at the domain apex with the value applane-verify= shown in the console, then click Verify. DNS takes minutes to a day. Source: https://docs.applane.dev/console/verify-domain/ **Who:** Whoever manages your DNS. The Applane admin clicks Verify. **Time:** 5 minutes, plus DNS propagation Before the extension will serve your domain, Applane checks that you control it. Without this, anyone could register your domain and point your employees at a hostile sign-in. ## Add the record **Setup > Verify your domain** shows the value. Add one TXT record at the apex of the domain your employees sign in with: ```text Type TXT Name @ (the bare domain, for example acme.com) Value applane-verify= TTL 300 or your default ``` Add it alongside any TXT records already there (`v=spf1`, `google-site-verification`); do not replace them. ## Verify Click **Verify** in the console. Applane looks up the TXT records at your domain and passes when one of them matches. DNS changes take from a minute to a day to show up. The console re-checks each time you click; "No matching record yet" lists the TXT values it did find, so you can tell a propagation delay from a typo. You can check from a terminal too: ```bash dig +short TXT ``` ## While you wait Everything else on the checklist can be done before the domain verifies. Only the first sign-in from the extension depends on it: until then builders see `unknown_domain`. See [Error messages](https://docs.applane.dev/reference/errors/#unknown_domain). ## More than one domain A trial or self-serve company has one domain. Alias domains (`acme.co.uk` next to `acme.com`) are added on Enterprise; write to support with the list, and each one gets its own TXT record. ## Remove it later Keep the record as long as you use Applane; it is re-checked. When you [uninstall](https://docs.applane.dev/workspace-admins/uninstall/), delete it. --- # Setup checklist > The five steps on the console's Setup page: domain, GCP project, OAuth client, Workspace admin, run checks. What each one needs and which check closes it. Source: https://docs.applane.dev/console/setup-checklist/ **Who:** The Applane admin, collecting values from the DNS owner, the GCP admin and the Workspace admin **Time:** 10 minutes once the values are in hand **Setup** is the home screen of the console until every step passes. Each step is a card with a lamp: green passed, red failed, amber warning, hollow not yet checked. Passed steps collapse to their title. ## Step 1: Verify your domain The TXT record and a **Verify** button. Details on [Verify your domain](https://docs.applane.dev/console/verify-domain/). ## Step 2: Google Cloud project Two fields: the project id and the builders group email. Once both are filled, **Download applane-setup.sh** generates the script with your values in it, and two links point at the Terraform module and the setup pages for GCP admins. Hand the script or the links to your GCP admin: [Set up the project](https://docs.applane.dev/gcp-admins/setup/). Nothing is checked from this step; step 5 confirms the APIs and the IAM grant. ## Step 3: OAuth consent screen and client The two redirect URIs, with copy buttons, and a field for the client id. Your GCP admin creates the client following [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) and [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/), then gives you the id. Paste it and click **Test sign-in**. A popup runs Google's sign-in once with that client id, asking for `openid email` only, and returns to `https://admin.applane.dev/oauth-probe`. The token stays in your browser. | Result | Meaning | |---|---| | "Signed in as you@yourdomain. Consent screen and client work." | Done. The id is saved. | | "Google returned `access_denied`." | The consent screen is not Internal, or the account is outside your organisation. | | "Google did not return to the console." | The popup shows the error; usually `redirect_uri_mismatch` (check both URIs, trailing slash included) or `invalid_client` (check the id). | | "The browser blocked the popup." | Allow popups for `admin.applane.dev` and try again. | | "Signed in as bob@other.com, not at yourdomain." | The client works, but sign in with an account at your domain to be sure the screen is Internal. | Every error is explained in [Error messages](https://docs.applane.dev/reference/errors/). ## Step 4: Workspace admin Copy blocks for your Workspace admin: the extension id, the force-install policy JSON with your domain filled in, and the one line about the per-user Apps Script API setting. Send them [Chrome extension policy](https://docs.applane.dev/workspace-admins/chrome-extension-policy/). Two fields for you: the bot account email and the admin group email, both at your domain. The Workspace admin creates them: [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/). Click **Save**. ## Step 5: Run checks Click **Run checks**. Each row gets a lamp and a one-line detail. | Row | Pass reads | On failure | |---|---|---| | Domain verified | "yourdomain verified" | Add the TXT record in step 1. | | Client id saved | "Client id saved" | Paste it in step 3. | | Test sign-in | "Test sign-in passed" | The probe's error, verbatim. | | APIs enabled | "5 of 5 APIs enabled on ``" | The missing API and the command that enables it. | | Vertex IAM | "`applane-builders@yourdomain` has `roles/aiplatform.user`" | The `gcloud projects add-iam-policy-binding` line. | | Apps Script API | "Apps Script API reachable" | The per-user setting link. | | Extension policy | Manual | Tick **Done** once the Workspace admin has allowed or force-installed the extension. | | Bot account | Manual | Tick **Done** once `applane-bot@` exists and has a licence. | | Admin group | Manual | Tick **Done** once `applane-admins@` exists. | Manual rows record who ticked them and when. When every row passes: "Setup complete. The first sign-in from the extension will show up under People." The home screen becomes [People](https://docs.applane.dev/console/people-and-seats/) and Setup stays in the navigation without a badge. ## Then Install the extension and sign in yourself: [Install and sign in](https://docs.applane.dev/builders/install-and-sign-in/). Your seat appears under People within a minute. --- # How do seats work in Applane? > A seat is one Workspace user who signed in to the extension. Open or allowlist mode, a cap, reclaim after 60 idle days, block, and inviting admins. Source: https://docs.applane.dev/console/people-and-seats/ **Who:** Applane admin or owner **Time:** Ongoing; a minute per action A seat is one Workspace user at your domain who has signed in to the extension. Builders are seats. People who only open a deployed app are never seats: they are not counted, not reported, and not visible to Applane. A seat is created at the first successful sign-in and stays active until it is reclaimed or blocked. There is no minimum number of seats. ## The readout **People** opens with "N active of M seats" and a bar. The bar turns amber at 90% of the cap and red at 100%. Emails go to every admin at both marks. ## Seat modes | Mode | Who gets a seat | |---|---| | Open (default) | Any verified user at your domain, first come first served, up to the cap. Matches a force-install rollout: employees click the icon and it works. | | Allowlist | Only emails on the allowlist. Others see "ask your admin" with the admin addresses. For companies that bought seats for a named group. | Switch modes with the control above the table. In allowlist mode an editor appears: add addresses one per line or comma-separated, remove with the button next to each. Addresses outside your domain are refused. ## The cap The trial cap is 10. After subscribing, monthly plans have no fixed cap (you pay for active seats each month) and the cap field is a limit you choose; annual plans buy a block of N seats and the cap is N. Existing seats are never cut off by a cap change. Only new sign-ins are refused. A refused sign-in shows as a `cap_refused` event with a **Raise cap** link. ## The seats table Columns: email, status (active, reclaimed, blocked), last seen, extension version, source (sign-in or admin). The per-row menu: | Action | Effect | |---|---| | Reclaim seat | Frees the seat now. The person's next sign-in re-activates it if there is room. Use it for leavers: [Offboarding](https://docs.applane.dev/workspace-admins/offboarding/). | | Block | Refuses this person even in open mode, until unblocked. | | Unblock | Lifts the block. | Seats are also reclaimed automatically after 60 days without a sign-in. Reclaimed rows are kept 12 months for invoice disputes, then deleted. ## Seat events The last 50 events under the table: activated, reclaimed, blocked, `cap_refused`, `allowlist_refused`, with time, email and who did it. ## Invite admins **Invite admin** opens a dialog: email at your domain, and a role. | Role | Can | |---|---| | Admin | Everything except billing and managing admins. | | Owner | Everything. | There is no accept step. The invitee signs in at `https://admin.applane.dev/signin` with that address and lands on your company. An email tells them so. Owners can remove any admin except themselves. Only owners see the Invite button. Admins see the owners' addresses instead. ## How seats become an invoice Monthly plans: a daily job counts active seats and sends the number to the billing provider as the subscription quantity. You pay for who used it that month. Annual plans: you bought N; if more than N are active, admins get a weekly email. See [Billing](https://docs.applane.dev/console/billing/). --- # How does Applane billing work? > €12 per builder per month or €120 per year, a 14-day trial with no card, no minimum, cancel any time. Gemini is billed by Google to your own project. Source: https://docs.applane.dev/console/billing/ **Who:** Owner **Time:** 3 minutes to subscribe Applane costs €12 per builder per month. Annual is €120 per builder per year, two months off. There is no minimum, no setup fee, and no AI usage fee: Gemini runs in your own GCP project and Google bills you for the tokens directly. A builder is an active seat, someone who signed in to the extension. People who only open the apps are free. See [People and seats](https://docs.applane.dev/console/people-and-seats/). ## The trial Signing up starts a 14-day trial with up to 10 builders. No card. A banner under the top bar shows the days left; it turns amber with 3 days to go, and an email goes to every admin then. ## Subscribe **Billing** shows your plan, the trial end or period end, and the seat count. Pick monthly or annual and click **Subscribe**. Checkout opens; the card is entered there and never touches Applane. - During the trial: the first charge happens on the trial end date. - After the trial has ended: the first charge is immediate, and the builder unlocks within 12 hours or at the next sign-in. Monthly: seats are counted daily and billed at the period end for the count on that day, so a seat that came and went mid-month is not prorated. Annual: you buy N seats; adding more mid-term creates a prorated invoice for the rest of the term. ## Manage billing Once subscribed, **Manage billing** opens the billing portal: change the card, download invoices, switch interval, cancel. Invoices are PDFs with your company name and VAT number; EU companies with a valid VAT number are reverse-charged. ## Cancel Cancel any time from the portal. The subscription runs to the end of the paid period, then the builder locks: build, deploy and publish refuse, opening existing apps keeps working. The apps themselves keep running; they are in your Google. Subscribe again and everything is where you left it. Nothing is deleted for 90 days. ## If the trial ends without a subscription The builder locks the same way. The console stays open with a **Subscribe** button on every page. Seats are not reclaimed. 30 days later the company goes to churned: the extension can no longer find it and the console shows only the billing page. Data is deleted after 90 days. ## If a payment fails An email goes to every admin, and a banner asks you to update the card. Seats keep working for 30 days. After 30 days past due the company is suspended: existing builders keep working through the 7-day licence grace, then the builder locks until the card is fixed. See [Licence tokens and offline behaviour](https://docs.applane.dev/security/licence-and-offline/). ## Enterprise Annual invoice, net 30, bank transfer, a purchase order number on the invoice, your own DPA reviewed if you need it, allowlist seat mode, more than one domain. **Talk to us** on the Billing page opens an email with your company in the subject. --- # Settings > What each field on the console's Settings page does: OAuth client, LLM, platform ACL, coordination sheet, telemetry, data allowlists and feature toggles. Source: https://docs.applane.dev/console/settings/ **Who:** Applane admin **Time:** 5 minutes **Settings** holds the tenant configuration. Builders receive a new version within 12 hours or at their next sign-in; "Saved. Config version N." next to the button tells you it went through. ## OAuth client | Field | What it does | |---|---| | Client id | The Web application client in your GCP project. Every builder's sign-in uses it. Changing it means every builder signs in again with the new one. [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) | ## LLM | Field | What it does | |---|---| | Vertex project | The GCP project Gemini calls are billed to. Usually the same project as the OAuth client. Must have `aiplatform.googleapis.com` on and the builders group granted `roles/aiplatform.user`. | | Default model | The Gemini model a new build uses. | | Allowed models | The models builders may switch to. Leave only the default if you want one bill line. | ## Platform ACL | Field | What it does | |---|---| | Bot account | The Workspace account that publishes external and public apps, so they outlive their builder. [Accounts and groups](https://docs.applane.dev/workspace-admins/accounts-and-groups/) | | Admin group | The group made editor on every published app. Members see the whole app inventory in the extension. | | Enforce | When on, publishing refuses unless the bot and the admin group are editors on the app. Keep it on; it is what makes an app survive offboarding. | ## Coordination sheet | Field | What it does | |---|---| | Sheet id | A domain-editable Google Sheet the extension uses for presence: who has an app open right now, so two builders do not overwrite each other. Leave empty to turn presence off. | ## Telemetry (Enterprise) | Field | What it does | |---|---| | Gateway URL, ops project, ops dataset, log project | Where usage events land in your own BigQuery for the cost dashboard. Everything stays in your project; Applane receives nothing. Only shown on plans that include it. | ## Data | Field | What it does | |---|---| | BigQuery allowlist | Which projects and datasets apps may query, as project to `*` or a list of datasets. Anything not listed is refused before the query runs. | | Firestore projects | Projects whose Firestore snapshots apps may read. | | Warehouse notes | Free text the agent reads when it builds against your data: naming conventions, which tables to prefer. | | Mailer domains | Domains an app may send email to. Empty means your own domain only. | ## Features | Toggle | What it does | |---|---| | Audiences: internal, external, anonymous | Which audiences a builder may choose when creating an app. Turn external and anonymous off for an internal-only company; the Drive sharing policy must allow them anyway. [Drive sharing policies](https://docs.applane.dev/workspace-admins/drive-sharing/) | | MCP bridge | Whether builders may connect Claude Code or Claude Desktop. [Connect Claude Code](https://docs.applane.dev/builders/claude-code/) | | Telemetry | Turns the telemetry module on for builders. Plan-gated. | | Firestore | Lets apps read Firestore snapshots. | | Context caching (default on) | Lets the extension keep each build turn's system prompt in a Vertex AI context cache, which cuts model cost per turn by 79 to 90%. Vertex serves caches only from its `global` location, even for requests routed to `eu`. Turn it off to keep every request in the model's region; input is then billed uncached and the Costs panel shows "Context cache: off — disabled for this company". Details on [Model cost](https://docs.applane.dev/gcp-admins/model-cost/#context-caching). | A toggle that the plan does not include shows a one-line note instead of a switch. Validation is one line under the field: "Enter a Vertex project id.", "Bot email must be at yourdomain.", "Not a valid dataset name". **Save** is enabled only when something changed and validation passes. --- # Audit log > Applane's own record of admin actions and seat changes, filterable and exportable as CSV. Google's logs stay in your project and Admin console. Source: https://docs.applane.dev/console/audit-log/ **Who:** Applane admin **Time:** 1 minute **Audit** lists Applane's own records: who changed the configuration, verified a domain, reclaimed or blocked a seat, invited an admin, or ticked a manual setup check. Each row has the time, the actor, the action, the target, and a **Details** toggle with the full payload as JSON. Filter by action or actor. **Export CSV** downloads the filtered rows. ## What is not here Google keeps its own logs, in your project and your Workspace, and they never pass through Applane: | What | Where | |---|---| | Vertex AI calls: who, when, which model | Cloud Audit Logs in your GCP project | | Apps Script executions | Apps Script dashboard and Cloud Logging in your project | | Drive activity on the app files | Drive audit log in the Google Admin console | | OAuth grants and revocations | Security > API controls in the Google Admin console | ## Retention Audit rows are kept 12 months. See [Where things are stored](https://docs.applane.dev/security/where-things-are-stored/). --- # How do I install Applane and sign in? > Install from the Chrome Web Store or get it force-installed, sign in with your work account, and turn on the Google Apps Script API once. Source: https://docs.applane.dev/builders/install-and-sign-in/ **Who:** Builder: anyone in the builders group **Time:** 3 minutes ## Install If your IT team force-installed Applane, the icon is already in your Chrome toolbar. Skip to sign in. Otherwise, install it from the Chrome Web Store listing your IT team sent you, or search for Applane there. If the store says the extension is blocked by your administrator, ask IT to allow it: [Chrome extension policy](https://docs.applane.dev/workspace-admins/chrome-extension-policy/). Applane works in Chrome, Edge and Brave. ## Sign in 1. Click the Applane icon. The side panel opens. 2. If asked, type your work email. Most managed setups skip this because IT pinned the company domain. 3. Google's sign-in opens under your company's own app name (for example "Applane (Acme)"). Pick your work account and accept the permissions. What each one is for: [Scopes reference](https://docs.applane.dev/security/scopes/). 4. The panel opens on your workspace. Use your work account. A personal Google account is refused before anything runs. ## Turn on the Apps Script API The first time, the panel shows a card: "Turn on the Apps Script API". This is a personal Google setting that has nothing to do with Applane; without it Google refuses to create Apps Script projects for you. 1. Click the link, or open [script.google.com/home/usersettings](https://script.google.com/home/usersettings). 2. Set **Google Apps Script API** to **On**. 3. Come back to the panel. It re-checks on its own. More on why: [Apps Script API per-user setting](https://docs.applane.dev/workspace-admins/apps-script-api/). ## If sign-in refuses you | Message | What it means | Who fixes it | |---|---|---| | `unknown_domain` | Your company has not verified its domain with Applane yet. | The Applane admin. [Verify your domain](https://docs.applane.dev/console/verify-domain/) | | `seat_cap_reached` | All seats are taken. The message names the admins to ask. | The Applane admin raises the cap or frees a seat. | | `not_allowlisted` | Your company uses an allowlist and you are not on it. | The Applane admin adds you. | | `extension_too_old` | Your version is below the minimum. | You: update at `chrome://extensions`, or wait for the managed update. | | `billing_required` | The trial or subscription has ended. | The owner. [Billing](https://docs.applane.dev/console/billing/) | | `access_denied` from Google | The consent screen is not Internal, or you used the wrong account. | Try your work account; then the GCP admin. | All of them in one place: [Error messages](https://docs.applane.dev/reference/errors/). ## Next [Your first app](https://docs.applane.dev/builders/first-app/). --- # How do I build my first app? > Open a sheet, describe the tool in plain words, check the sandbox preview, click Deploy. The app lands in your Drive as an Apps Script web app with a URL. Source: https://docs.applane.dev/builders/first-app/ **Who:** Builder **Time:** 10 minutes An app in Applane is a Google Apps Script web app. You describe it, the agent writes it inside a fixed template, you see it run in a preview, and you deploy it. It lands in your Drive with a URL on `script.google.com`. ## 1. Start from data Open the sheet, doc or folder you want the tool to work on, then open the side panel. The agent can read what you point it at; a sheet with clear column headers is the best first input. Click **New app**. Pick the audience: **Internal** for a tool your colleagues open with their work account. That is the right choice for a first app; the other two are explained in [Sharing an app](https://docs.applane.dev/builders/sharing/). ## 2. Describe it Write what the tool should do in plain words, as you would to a colleague. Say which sheet or table it reads, what a person does with it, and what it should write back, if anything. For example: > A form to log a customer visit. Read the customer list from the "Accounts" tab, let me pick one, add a date, a contact and notes, and append the visit to the "Visits" tab. The agent reads the sheet's headers, writes the app, and shows it in the preview. ## 3. Look at the preview The preview runs the app in a sandbox inside the panel, against your real data, with your own account. Click through it. If something is wrong, say so in the next message: "the date should default to today", "sort accounts by name". Each turn goes through the same validator, so the app never leaves the template. ## 4. Deploy Click **Deploy**. Applane creates an Apps Script project in your Drive (or updates it), pushes the files and creates a web-app deployment. You get a URL. An internal app runs as whoever opens it, and Google only lets in accounts at your domain. Nobody can see data through it that they could not already see themselves. ## 5. Come back later Your apps are listed on the panel's home screen, along with the apps shared with you. Open one to keep building; the source is pulled from the Apps Script project, so it works from any machine. The project is also visible at [script.google.com](https://script.google.com) like any other. ## What the agent can and cannot do It reads sheets, docs and the BigQuery tables your company allows, and writes app code. It cannot change the app's permissions, share it, publish it to partners or the public, or run a BigQuery query above the cost limit without asking you. Those are yours: [Sharing an app](https://docs.applane.dev/builders/sharing/). Chat history and drafts stay in your browser. Nothing you type reaches Applane; the model runs in your company's own GCP project. --- # How do I share an Applane app? > Who can open an app is its audience, fixed at creation: internal, external or anonymous. Who can edit its source is a Drive permission on the project. Source: https://docs.applane.dev/builders/sharing/ **Who:** Builder; the bot account for external and public apps **Time:** 2 minutes Sharing an app is two separate things. ## Who can open it: the audience The audience is chosen when the app is created and cannot be changed afterwards. Changing it would change the app's manifest and template, which makes it a new app. The home screen shows an audience pill on each app: none for internal, amber for external, red for public. | Audience | Who can open the app | Runs as | Notes | |---|---|---|---| | Internal (default) | Anyone signed in at your domain | The viewer | Google rejects any other login before the code runs. Send colleagues the URL; nothing else to do. | | External (partner portal) | Named partner accounts, from an allowlist inside the app | The viewer, with no access to company data; reads go through a paired gateway | Published from the bot account. Needs external sharing allowed by IT. | | Anonymous (public link) | Anyone with the link | The bot account | Only data that is already public may be shown; the platform enforces a grant table. Published from the bot account. | ### External and public apps need the bot Partner-facing and public apps are deployed from the bot account, so they keep running when their builder leaves. Publishing one is a two-step: build it as yourself, then publish from a session signed in as the bot, with `applane-admins@` as editor. The extension refuses to publish otherwise when enforcement is on. If **New app** does not offer these audiences, your company turned them off, or IT has not allowed external sharing. [Drive sharing policies](https://docs.applane.dev/workspace-admins/drive-sharing/), [Settings](https://docs.applane.dev/console/settings/). ### Anonymous: public link An anonymous app runs as the bot account for everyone who opens it, so anything it reads it reads with the bot's rights. The platform only lets it read sources you explicitly grant, and refuses grants on data that is not already public. Treat a public app like a page on your website. ## Who can edit the source: a Drive permission The app's source is an Apps Script project, which is a file in your Drive. Who can edit it is a Drive permission. The **Share** entry in the app menu opens Google's own share dialog for that file. Add a colleague as editor and they can open the app in their own panel and keep building. Applane never changes these permissions itself; it only reads them to show "Shared with: ...". Whether you can add someone outside the company is decided by your Workspace's Drive sharing policy. ## Working on the same app When two people have the same app open, the panel shows who else is there and locks the composer for the second person until the first is done. That needs the coordination sheet your admin set in [Settings](https://docs.applane.dev/console/settings/). ## Take-over Every published app has `applane-admins@` as editor, so IT can open, repoint or transfer any app without you. That is what makes an app outlive its builder: [Offboarding](https://docs.applane.dev/workspace-admins/offboarding/). --- # What is an advisory? > An advisory flags an app that needs a fix because the platform changed after it was built. Severity runs from info to emergency; fixes from re-push up. Source: https://docs.applane.dev/builders/advisories/ **Who:** Builder **Time:** Usually one click Most of a deployed app is platform-owned: the manifest, the configuration file and the shared files are rewritten on every push, and only a handful of files carry what makes your app yours. When the platform changes, an app that was built before the change may need a small fix. An advisory is how the panel tells you. ## Where they show up - On the home screen, a marker on each affected app. - Inside an app, a strip above the composer with the advisory's name, its severity, and a button for the fix. The panel checks the app's actual content before it shows an advisory, so it only flags apps that are affected. ## Severity | Severity | What it means | Deploy | Publish | |---|---|---|---| | Info | Good to know. | Allowed | Allowed | | Warning | Should be fixed soon. | Allowed, with a warning | Asks you to confirm | | Critical | Must be fixed. | Allowed, with a warning | Blocked until fixed, or dismissed with a reason | | Emergency | A dependency the app loads was compromised, or similar. | Blocked unless the push itself is the fix | Blocked, no dismissal | For an emergency the platform may apply the fix on its own, because waiting for a click is not a safe response to an app that is serving hostile code. The fix in that case is always a plain re-push or a swap of a pinned dependency, never something the agent decides. ## Fixes | Fix | What happens | |---|---| | Re-push | Pushes the platform's own files again. One click, nothing of yours changes. | | Transform | A defined edit to your files, shown in the preview before deploy. | | Repair prompt | The agent gets a canned instruction as a normal turn; you review the result as usual. | | Re-publish | The live deployment still serves an old version; re-publish it (from the bot for external and public apps). | | Config change | A setting or grant needs updating; the panel walks you through it. | | Regenerate | The old code cannot be carried over; the agent rebuilds it with a review checklist. | Click the button in the strip. The fix runs through the same validator and preview as any other change. ## Dismissing Warnings and critical advisories can be dismissed with a reason, which is stored with the app. Emergencies cannot. --- # How do I connect Claude Code or Claude Desktop to Applane? > Register applane-mcp as an MCP server, start Claude, type the six-digit pairing code into the panel. The agent builds with your token, in front of you. Source: https://docs.applane.dev/builders/claude-code/ **Who:** Builder with Node.js installed; the Applane admin must have the MCP bridge turned on **Time:** 5 minutes Claude Code and Claude Desktop can drive the Applane builder through an MCP bridge. The bridge is a small local server that Claude Code or Claude Desktop starts; the extension's workspace tab connects to it over loopback. The agent's calls go through the same validator, the same preview and the same token as when you type, and the panel shows what the agent is doing. Nothing new is installed in your Google, and no extra permission is granted: the agent uses your existing sign-in. ## 1. Get the bridge `applane-mcp` ships in the Applane repository as `packages/mcpb`. Your admin or IT will tell you where it is checked out. It needs Node.js 22 or newer and nothing beyond the repository's own dependencies. ## 2. Register it with Claude Add to Claude Code or Claude Desktop's MCP configuration: ```json { "mcpServers": { "applane": { "command": "node", "args": [ "--experimental-transform-types", "/packages/mcpb/src/main.ts", "--extension-id", "" ] } } } ``` `--extension-id` is the id from `chrome://extensions`. Without it the bridge refuses every connection. | Flag or variable | Meaning | |---|---| | `--extension-id`, `APPLANE_EXTENSION_ID` | Which extension may connect. Required. | | `--port`, `APPLANE_BRIDGE_PORT` | Pin one port instead of trying 8765 to 8774. | | `APPLANE_BRIDGE_CALL_TIMEOUT_MS` | How long one forwarded call may run. Default 120000. | ## 3. Pair 1. Start Claude Code or Claude Desktop. The bridge prints a six-digit pairing code to its terminal (Claude Desktop: the MCP server log). 2. In the Applane panel, open the app you want the agent to work on and choose **Connect agent** from the ⋮ menu in the top bar. 3. Type the code. The panel finds the bridge on the local port range and connects. The code lives only in the bridge's memory and dies with the session. Typing it is the authorisation step: no code, no connection. ## 4. Work The panel shows a bar naming the connected agent and locks the composer while the agent is driving. The agent can read the app, propose changes, deploy to dev and read advisories. It cannot publish, share, change permissions, run a BigQuery query above the cost limit or act outside the one app you paired it on; for those it raises a card that you approve or carry out yourself in Google's own dialog. **Disconnect** in the bar ends the session. Closing Claude does too. ## If it does not connect - "no tab is paired": the panel is not connected yet. Type the pairing code. - The panel finds no bridge: check Claude is running and, if you pinned `--port`, that it matches. - The composer stays locked after Claude closed: click **Reconnect** or **Disconnect** in the bar. --- # What data reaches Applane? > Your domain name, a Google ID token used once, and what admins type in the console. Never a Google access token, app source, prompt or row of your data. Source: https://docs.applane.dev/security/data-flow/ Your employees' browsers talk to Google with tokens minted by your OAuth client in your GCP project. The apps run on your Apps Script. The model runs on your Vertex AI billing. The audit trail is your Cloud Audit Logs. Applane's backend stores your configuration, the email addresses of the people who build, and your invoice. ## What reaches Applane | From | What | Why | Kept? | |---|---|---|---| | The extension, before sign-in | Your domain name | To find your company's record and return its OAuth client id | No | | The extension, at sign-in | A Google ID token: your email, your domain, a nonce | To prove who is signing in before issuing a licence. Checked, then discarded. | The email becomes a seat row. The token is not stored. | | The extension, daily | The same, to renew the licence | Same | Same | | The admin console | What admins type: company name, project id, client id, group and bot addresses, settings, seat actions | To run the company | Yes, as the tenant record and the audit log | | The setup checker | Pass or fail per check | To show the checklist | Yes, pass/fail only | | Checkout | Nothing; the card goes to the payment provider | Billing | The provider holds it | Back from Applane to the extension: the tenant configuration and a signed licence. ## What never reaches Applane - Google access tokens or refresh tokens. The extension holds them in Chrome's identity plumbing and sends them to Google only. - App source, files or versions. They live in Apps Script projects in your Drive. - Prompts, chat history or agent transcripts. They live in the builder's browser; the model call goes from the browser to Vertex AI in your project. - Sheet, Doc, Drive, BigQuery or Firestore contents. - Who opens or uses a deployed app. Viewers are never counted or seen. - A copy of your app inventory. The contract types the extension is built against have no field for any of these, so they cannot be sent by accident. ## Where each call goes | Call | From | To | With | |---|---|---|---| | Sign in | Extension | `accounts.google.com`, your client | The employee's Google session | | Build (model call) | Extension | Vertex AI in your project | The employee's token, `cloud-platform` scope | | Create, push, deploy an app | Extension | Apps Script API | The employee's token, `script.*` scopes | | Read sheets, docs, Drive | Extension | Sheets, Docs, Drive APIs | The employee's token | | Run an app | The viewer's browser | `script.google.com` | The viewer's own Google session | | Find the company, get a licence | Extension | Applane API | Domain, then ID token | | Admin console | Admin's browser | Applane | Applane's own sign-in (`openid email profile`) | The setup checker's test sign-in runs from the admin's browser against Google; the token it gets stays there. ## Hosting Applane's backend runs on Supabase in Frankfurt (AWS `eu-central-1`), behind Cloudflare with EU data localisation on. Payments are on Stripe. Transactional email goes through an EU provider. No US transfer for the data Applane processes on your behalf. See [DPA and sub-processors](https://docs.applane.dev/security/dpa-and-sub-processors/). --- # Which OAuth scopes does the Applane extension request? > Sign-in, Apps Script projects, deployments and processes, Sheets, Drive read-only and cloud-platform. Granted to your own client; no verification applies. Source: https://docs.applane.dev/security/scopes/ The extension requests these scopes at sign-in. They are granted to your own OAuth client, never to an Applane client. Because the consent screen is Internal, no scope needs Google verification and no CASA assessment applies. See [No Google app verification needed](https://docs.applane.dev/gcp-admins/no-verification-needed/). Google's classification is shown so a reviewer can map it to policy. | Scope | Google's class | What the extension does with it | |---|---|---| | `openid`, `email` | Non-sensitive | Sign the employee in and check that the account is a verified member of your Workspace domain. Any other account is rejected and its token revoked. | | `https://www.googleapis.com/auth/script.projects` | Sensitive | Create the Apps Script project for each app and push its files. The project is a Drive file owned by the builder. | | `https://www.googleapis.com/auth/script.deployments` | Sensitive | Create and update the web-app deployment that gives each app its URL, and repoint it for publish and kill-switch actions. | | `https://www.googleapis.com/auth/script.processes` | Sensitive | Read-only execution history, so the extension can tell a builder that a scheduled run failed. | | `https://www.googleapis.com/auth/spreadsheets` | Sensitive | Read sheet schemas while building, and let apps on the read-write tier write to sheets as the signed-in viewer. | | `https://www.googleapis.com/auth/drive.readonly` | Restricted | List the apps shared with the builder and read the docs, slides and folders they point the agent at. Never writes. | | `https://www.googleapis.com/auth/cloud-platform` | Sensitive | Call Vertex AI (Gemini) in your GCP project with the builder's own identity, so usage is attributed and billed to you. | ## About `cloud-platform` It is the broadest GCP scope, and reviewers ask about it. Three things bound it: 1. A token is only as powerful as its user's IAM. A typical employee holds no GCP role beyond the `roles/aiplatform.user` grant Applane's setup adds, so the scope unlocks Vertex calls and nothing else for them. 2. The client is Internal and the token never leaves Chrome's identity plumbing; it is not sent to Applane. 3. Generated app code runs in a sandbox that cannot reach the token. Engineers who do hold real GCP roles should know the extension could act with them; the sandbox is the mitigation. ## Scopes are fixed per build The list is decided by the extension build, not per company. Turning the external or anonymous audiences off in [Settings](https://docs.applane.dev/console/settings/) hides those features; it does not change the consent screen. ## Revoking A Workspace admin sees the grant per user under **Security > API controls > Manage third-party app access**, under your app's name, and can revoke it there. A user can do the same at [myaccount.google.com/permissions](https://myaccount.google.com/permissions). Either signs them out of the extension. --- # Where is my data stored? > Apps and data stay in your Google. Chat history stays in the browser. Applane holds tenant config, admin and builder emails, seat events and invoices. Source: https://docs.applane.dev/security/where-things-are-stored/ ## In your Google | Data | Where | |---|---| | App source and every version | An Apps Script project per app, a Drive file owned by the builder. Google's own revision history. | | Deployed apps | Apps Script web-app deployments on `script.google.com`. | | The data apps read and write | Your Sheets, Docs, Drive, BigQuery, Firestore. Apps read them as the viewer. | | Model calls | Vertex AI in your project. Request logging follows your project's settings; the default logs no content. | | Presence (who has an app open) | The coordination sheet, if you set one. | | Usage telemetry (Enterprise) | A BigQuery dataset in your own project. | | Audit of Google actions | Cloud Audit Logs, the Apps Script dashboard, the Drive audit log, the Admin console. | ## In the builder's browser Chat history, drafts, the cached tenant configuration and the licence token, in Chrome's extension storage. No Google token is written to storage; tokens stay in Chrome's identity API. Clearing the extension's data loses chat history and nothing else; the apps are in Drive. ## In Applane | Data | Retention | Personal data? | |---|---|---| | Company name, verified domains, plan | Life of the contract plus 30 days | No | | Tenant configuration: OAuth client id, GCP project id, group and bot addresses, feature flags, allowlists | Same | Group and bot addresses only | | Admin emails and roles | Same | Yes | | Builder emails, first and last seen, extension version | Same; reclaimed seats kept 12 months for invoice disputes | Yes | | Seat events and admin actions (the audit log) | 12 months | Actor emails | | Billing records | 7 years (Dutch bookkeeping law) | Billing contact, held by the payment provider | | Server logs: request id, path, status, IP address | 30 days | IP address | Not stored: Google tokens, app source, prompts, transcripts, sheet or document contents, app viewers, an inventory of your apps. See [Data flow](https://docs.applane.dev/security/data-flow/). ## Deletion - Closing the company deletes every tenant row within 30 days. Billing records stay for the legal period. - A builder's rows are deleted on the admin's request within 30 days. - A subject access request: the admin exports the builder's rows (seat, events) from the console; the company handles its employee. ## Backups The database is backed up daily by the hosting provider, in the same EU region. --- # DPA and sub-processors > Applane is a processor for admin and builder emails, a controller for billing contacts. Sub-processors: Supabase, Cloudflare, Stripe, an EU email provider. Source: https://docs.applane.dev/security/dpa-and-sub-processors/ ## Roles For the data Applane holds about your employees (admin and builder email addresses, seat activity), Applane is a **processor** acting on your instructions: you decide who uses the product. For your billing contact, Applane is a **controller**. Applane does not process the contents of your apps, your sheets, your prompts or your documents, because none of it reaches Applane. See [Data flow](https://docs.applane.dev/security/data-flow/). ## Sub-processors | Sub-processor | Purpose | Location | |---|---|---| | Supabase | Database and backend functions: tenant configuration, seats, licences | Frankfurt, Germany (EU) | | Cloudflare | Network edge and static hosting for the website, the console and this site | EU data localisation enabled | | Stripe | Invoicing and payment processing | EU entity; Stripe holds the billing contact | | Email provider (to be named) | Transactional email: licence and admin notices | EU | Data stays in the EU. Changes to this list are announced to every admin by email at least 30 days before they take effect. ## The DPA Applane's data processing agreement is based on the standard EU processor clauses (GDPR Article 28). Its annex lists the two data categories (admin and builder emails; seat and admin activity), the sub-processors above, EU hosting, breach notification within 72 hours, the deletion timelines on [Where things are stored](https://docs.applane.dev/security/where-things-are-stored/), and audit rights met by this documentation. Request it from the support address shown in the console, or from the security page on [applane.dev](https://applane.dev/security). Companies that need their own paper can send it for review; the obligations are the same whatever the template says. ## Security controls, in short - Extension: no tokens in extension storage, sandboxed preview, no remote code, a content security policy. - Backend: row-level security on every tenant table, writes through audited functions, secrets in a vault, licences signed with ES256, ID token audience and nonce checks, rate limits on the public endpoints. - Operations: two-factor authentication on every account that can touch production, pinned dependencies with automated scanning, daily backups. - A written incident process: who is told, within what time, by which channel. SOC 2 is not in place. The interim evidence for a security review is this site, the [Data flow](https://docs.applane.dev/security/data-flow/) page, the Internal-client posture ([No Google app verification needed](https://docs.applane.dev/gcp-admins/no-verification-needed/)), the sub-processor list, and the DPA. --- # What happens when Applane is unreachable? > Licences last 72 hours and are accepted 7 more days offline, so builders keep working through a 10-day outage. Deployed apps never depend on Applane. Source: https://docs.applane.dev/security/licence-and-offline/ When a builder signs in, Applane's backend issues a licence: a small signed token that names the builder, the company, the plan and the features. The extension keeps it in Chrome's extension storage and checks it locally before any build, deploy or publish. The public keys that verify it are compiled into the extension, so the check needs no network. ## Lifetime | | | |---|---| | Valid for | 72 hours from issue | | Renewed | On workspace open when under 12 hours remain, by a silent Google sign-in and a call to Applane. A daily background refresh also runs as a best effort. | | Grace after expiry | 7 days. The licence is still accepted offline. | | After the grace | The builder locks: build, deploy and publish refuse with a one-line reason. Opening apps, reading transcripts and copying URLs keep working. | ## When Applane is unreachable | Applane | Time since expiry | Extension | |---|---|---| | Any state | Before expiry | Normal | | Down | 0 to 7 days | Normal, with an amber banner: "could not refresh licence" | | Down | More than 7 days | Read-only until it can renew | | Up, seat reclaimed | Any | The next sign-in re-activates the seat if there is room | So it takes 72 hours plus 7 days of continuous outage before any builder is affected. The apps themselves never depend on Applane being up; they run on your Apps Script. ## When the company is suspended A company is suspended when the trial ends without a subscription, after 30 days past due, or on request. Licences stop being renewed. Existing builders keep working through the 7-day grace, then lock. New sign-ins are refused with `billing_required`. Subscribing lifts it, and seats pick up within 12 hours or at the next sign-in. See [Billing](https://docs.applane.dev/console/billing/). ## What the licence contains The builder's email, the company id, the plan (`trial`, `team`, `enterprise`), the role (`builder` or `admin`), the enabled features, the configuration version, and the issue and expiry times. No Google token. The configuration version is how the extension knows to fetch new settings. ## Anti-abuse The licence check is client-side JavaScript. A company that patches the extension to skip it is in breach of contract, and that is the enforcement: per-seat B2B licensing is enforced by the invoice. There is no device fingerprinting, no hardware lock and no obfuscation. What is protected: an ID token cannot be replayed to mint a licence (it expires in an hour and carries a nonce), a licence cannot be forged (the private key never leaves the backend), and nobody can register your domain (DNS verification). --- # applane-setup.sh flags > Every flag of applane-setup.sh: --project, --group, --budget-account, --budget-amount, --extension-id, --dry-run and --check, with what --check prints. Source: https://docs.applane.dev/reference/setup-script/ `applane-setup.sh` prepares a GCP project for Applane, or checks one. It is add-only, prints every command before running it, and deletes nothing. Works with bash 3.2 (the macOS default) and `gcloud` 400 or newer. How to use it: [Script](https://docs.applane.dev/gcp-admins/setup/script/). ```text applane-setup.sh --project --group [options] applane-setup.sh --check --project --group ``` | Flag | Required | Meaning | |---|---|---| | `--project ` | Yes | GCP project in your Workspace organisation. | | `--group ` | Yes | Google Group that may build. Gets `roles/aiplatform.user`. | | `--budget-account ` | No | Billing account `XXXXXX-XXXXXX-XXXXXX`. Creates a budget alert when set. | | `--budget-amount ` | No | Monthly amount for the alert. Default 50, in the billing account's currency; `50EUR` style is also accepted. | | `--extension-id ` | No | The Applane extension id from the console. Only used to print the redirect URIs. Default: the `` placeholder. | | `--dry-run` | No | Print every command without running any. | | `--check` | No | Verify instead of change: APIs, IAM, billing, and print the manual steps. | | `-h`, `--help` | No | Usage. | ## What it does 1. `gcloud config set project`. 2. `gcloud services enable` for the [five APIs](https://docs.applane.dev/gcp-admins/apis/). Already-enabled APIs are a no-op. 3. `gcloud projects add-iam-policy-binding` for `roles/aiplatform.user` to `group:`. 4. With `--budget-account`: enable `billingbudgets.googleapis.com` and create a budget named `applane-vertex-` with alerts at 50%, 90% and 100%. 5. Print the two console steps ([consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/), [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/)) with the redirect URIs. ## What `--check` prints | Line | Check | |---|---| | `PASS API enabled: ` | One per API. `FAIL` prints the enable command. | | `PASS IAM: roles/aiplatform.user -> group:` | The binding exists. `FAIL` prints the binding command. | | `PASS Billing linked to ` | The project has a billing account. | | `INFO Apps Script API user setting` | Per user; cannot be checked here. [Apps Script API](https://docs.applane.dev/workspace-admins/apps-script-api/) | | `INFO OAuth consent screen and client` | Google has no API for it. The [console's checker](https://docs.applane.dev/console/setup-checklist/) tests it. | Exit code is non-zero when any line is `FAIL`. ## Permissions needed `serviceusage.services.enable` and `resourcemanager.projects.setIamPolicy` on the project (owner or editor). `roles/billing.costsManager` on the billing account for the budget. --- # Terraform module > Inputs, outputs and resources of the customer-gcp Terraform module: five APIs, one IAM binding, an optional budget, and why the OAuth client is not in it. Source: https://docs.applane.dev/reference/terraform-module/ Source: `github.com//applane//infra/terraform/customer-gcp`. How to use it: [Terraform](https://docs.applane.dev/gcp-admins/setup/terraform/) or [Infrastructure Manager](https://docs.applane.dev/gcp-admins/setup/infrastructure-manager/). Verified with Terraform 1.15 and `hashicorp/google` 6.50. ## Inputs | Name | Default | Notes | |---|---|---| | `project_id` | required | Existing project in your Workspace organisation. | | `builders_group_email` | required | Google Group of people allowed to build. | | `billing_account_id` | `null` | `XXXXXX-XXXXXX-XXXXXX`. The budget is created only when set. | | `budget_amount` | `50` | Monthly, in the billing account's currency. | | `enable_apis` | `true` | `false` if another module already manages `google_project_service` on this project. | | `existing_project` | `true` | `false` when the project is created in the same apply, which skips the billing check at plan time. | | `applane_extension_id` | `` | From the Applane console. Only feeds the redirect URI output. | | `admin_console_probe_uri` | `https://admin.applane.dev/oauth-probe` | The second redirect URI (the console's test sign-in). Override only for a non-production console. | ## Outputs | Name | What | |---|---| | `oauth_redirect_uris` | Both URIs the OAuth client needs. | | `consent_screen_instructions` | The two console steps, as text. | | `next_steps` | What to do after apply. | | `enabled_apis` | The five API names. | | `vertex_binding` | The IAM member and role. | | `budget_name` | The budget resource name, or empty. | | `project_id` | Echo of the input. | ## Resources | Resource | What | Why | |---|---|---| | `google_project_service` x5 | `script`, `aiplatform`, `sheets`, `drive`, `docs` `.googleapis.com` | The APIs the extension calls. `disable_on_destroy = false`: destroying the module never switches an API off. | | `google_project_iam_member` | `roles/aiplatform.user` to `group:` | Lets builders call Gemini on Vertex AI. | | `google_billing_budget` | 50%, 90%, 100% of `budget_amount` per month | Only when `billing_account_id` is set. Alerts only. Also enables `billingbudgets.googleapis.com`. | | `data "google_project"` | Read | Checks that billing is linked and fails the plan with a clear message if not. Skipped with `existing_project = false`. | ## Not in the module The OAuth consent screen and the OAuth client. Google has no API for either; the provider's IAP client resources do not work with the extension's sign-in. They are two console steps: [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/), [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/). ## Destroy Removes the IAM binding and the budget. The APIs stay on. See [Uninstall](https://docs.applane.dev/workspace-admins/uninstall/#gcp-admin). --- # Chrome policy JSON > The full chrome-policy.json for the Applane extension: force-install, allow-only and the managed storage tenantDomain block, with where each one goes. Source: https://docs.applane.dev/reference/chrome-policy/ This is `infra/scripts/chrome-policy.json` from the Applane repository. Where to paste it: [Allow or force-install the extension](https://docs.applane.dev/workspace-admins/chrome-extension-policy/). Replace `` with the id shown in the Applane console and `` with your Workspace domain. Use one of the two `ExtensionSettings` entries, not both. ```json { "ExtensionInstallForcelist": [ ";https://clients2.google.com/service/update2/crx" ], "ExtensionSettings": { "": { "installation_mode": "force_installed", "update_url": "https://clients2.google.com/service/update2/crx", "toolbar_pin": "force_pinned" } }, "ExtensionSettings_allow_only_alternative": { "": { "installation_mode": "allowed", "update_url": "https://clients2.google.com/service/update2/crx" } }, "ManagedStoragePolicyForApplane": { "tenantDomain": "" } } ``` | Block | What it is | |---|---| | `ExtensionInstallForcelist` | The classic force-install list: id and the Chrome Web Store update URL. Silent install, not removable. | | `ExtensionSettings` (`force_installed`) | The same as a per-extension setting, plus `toolbar_pin` so the icon is visible. Use this or the forcelist; both is harmless. | | `ExtensionSettings_allow_only_alternative` | Rename this key to `ExtensionSettings` if you want employees to install it themselves. Needed when your policy blocks unlisted extensions. | | `ManagedStoragePolicyForApplane` | The value to paste into the extension's own **Policy for extensions** box; it is not a Chrome policy key of its own. `tenantDomain` pins the company domain so employees never type it. Sign-in still checks the account's domain. | ## Where each block goes - Google Admin console: **Devices > Chrome > Apps & extensions > Users & browsers**. The console has its own form for install mode and pinning; the JSON is for reference. The managed storage block goes in the extension's **Policy for extensions** field. - Chrome Browser Cloud Management custom policies, Windows registry, macOS profile or Linux policy files: `ExtensionInstallForcelist` and `ExtensionSettings` as shown. Managed storage goes under `3rdparty/extensions//policy`. ## Verify Open `chrome://policy` on a managed profile and click **Reload policies**. The id appears under the relevant key. Under `chrome://extensions`, the extension shows "Installed by your administrator" when force-installed. --- # Applane error messages > Every error a builder or admin can see, from redirect_uri_mismatch to seat_cap_reached: what it means, who fixes it, and how. Source: https://docs.applane.dev/reference/errors/ ## From Google's sign-in page | Error | What it means | Who fixes it | How | |---|---|---|---| | `redirect_uri_mismatch` | The OAuth client is missing one of the two redirect URIs, or one differs: trailing slash, `http`, a typo in the extension id. | GCP admin | Paste both URIs exactly as the Applane console shows them. Google takes up to a minute to apply the change. [OAuth client](https://docs.applane.dev/gcp-admins/oauth-client/) | | `invalid_client` | The client id saved in the Applane console is wrong, or the client was deleted. | GCP admin, Applane admin | Copy the Client ID again from **Credentials**, check for a trailing space, save it in the console. If the client was deleted, create a new one. | | `access_denied` | The consent screen is not Internal, or the account is outside your organisation, or a Workspace admin blocked the app. | GCP admin; then the user; then the Workspace admin | Set the user type to Internal. Sign in with a work account. Check **Security > API controls > App access control**. [OAuth consent screen](https://docs.applane.dev/gcp-admins/oauth-consent-screen/) | | `admin_policy_enforced` | Workspace restricts third-party apps to a trusted list and this app is not on it. | Workspace admin | For the extension this should not happen because the client is yours; check the client belongs to a project in your organisation. For the admin console, trust it: [Third-party app access](https://docs.applane.dev/workspace-admins/third-party-app-access/). | | `org_internal` | A personal or external Google account tried to sign in to an Internal app. | The user | Expected. Use a work account. | ## From the Apps Script API ### Apps Script 403 | What it means | Who fixes it | How | |---|---|---| | The builder's personal **Google Apps Script API** setting is off. Every Apps Script API call for that user returns HTTP 403 until it is on. | The builder | Open [script.google.com/home/usersettings](https://script.google.com/home/usersettings), turn it on, return to the panel. The panel shows this as a card and re-checks on its own. [Apps Script API](https://docs.applane.dev/workspace-admins/apps-script-api/) | If the setting is on and 403 persists, check that `script.googleapis.com` is enabled on the project ([The five APIs](https://docs.applane.dev/gcp-admins/apis/)) and that **Apps > Google Workspace > Apps Script** is on for the builder's organisational unit. ## From Applane These come back when the extension asks Applane for the company record or a licence. ### `unknown_domain` | What it means | Who fixes it | How | |---|---|---| | No verified company matches the sign-in domain. Either nobody signed up, the TXT record is not in place yet, or the domain is an alias that was not added. | Applane admin, DNS owner | Add and verify the TXT record. If it was just added, wait for DNS and try again. [Verify your domain](https://docs.applane.dev/console/verify-domain/) | ### `seat_cap_reached` | What it means | Who fixes it | How | |---|---|---| | Every seat is active. The message names the admins to ask. Existing builders keep working. | Applane admin | Raise the cap, or reclaim an idle seat, under **People**. On trial the cap is 10; subscribe to raise it. [People and seats](https://docs.applane.dev/console/people-and-seats/) | ### `not_allowlisted` | What it means | Who fixes it | How | |---|---|---| | The company uses allowlist seat mode and this address is not on the list. | Applane admin | Add the address under **People > Allowlist**, or switch to open mode. | ### `extension_too_old` | What it means | Who fixes it | How | |---|---|---| | The installed version is below the minimum Applane accepts. The message carries the minimum version. | The builder, or the Workspace admin | Update at `chrome://extensions` (**Update** in developer mode), or wait for the managed update; force-installed extensions update on their own within hours. | ### `billing_required` | What it means | Who fixes it | How | |---|---|---| | The trial ended without a subscription, or the subscription lapsed. New sign-ins are refused; existing builders lock after the 7-day grace. | Owner | Subscribe or fix the card under **Billing**. Seats pick up within 12 hours or at the next sign-in. [Billing](https://docs.applane.dev/console/billing/) | ### `tenant_suspended` | What it means | Who fixes it | How | |---|---|---| | The company is suspended: 30 days past due, or on request. | Owner | Update the card in the billing portal, or write to support. | ### `domain_not_verified` | What it means | Who fixes it | How | |---|---|---| | The company exists but the domain check has not passed. Seen in the console, not the extension. | Applane admin | Click **Verify** once the TXT record is live. | ### `rate_limited` | What it means | Who fixes it | How | |---|---|---| | Too many requests from one address in a short time. | Nobody | Wait a minute. | ## In the Applane console | Message | What it means | How | |---|---|---| | "`acme.com` already has an Applane account." | Someone at your company signed up first. | Ask them to invite you from **People**, or write to support. | | "Google did not return to the console." | The test sign-in popup hit a Google error. | Read the error in the popup; it is one of the sign-in errors above. | | "The browser blocked the popup." | Popups are blocked for `admin.applane.dev`. | Allow them and try again. | | "Trial allows up to 10 seats." | The cap field is above the trial limit. | Subscribe to raise it. | | "Missing: `aiplatform.googleapis.com`." | One of the five APIs is off. | Run the [script](https://docs.applane.dev/gcp-admins/setup/script/) or enable it by hand. | --- # Glossary > Builder, seat, tenant, audience, advisory and the other words this site uses, with what each one means in Applane. Source: https://docs.applane.dev/reference/glossary/ | Term | Meaning | |---|---| | Builder | A person who signs in to the extension and builds apps. What the pricing page charges for. | | Seat | One builder, in the console's terms. A seat is created at the first sign-in and stays active until reclaimed or blocked. Builders and seats are the same thing. | | Viewer | Someone who opens a deployed app. Never counted, never seen by Applane. | | Tenant | A company in Applane: one verified domain (more on Enterprise), one OAuth client, one configuration, its seats and its subscription. "Company" on this site. | | Applane admin | A person who can sign in to the Applane console for a tenant. Owners can also manage billing and other admins. | | Audience | Who an app serves: internal (your domain), external (named partners), anonymous (a public link). Fixed when the app is created. | | Advisory | A notice on an app that needs a fix because the platform changed after the app was built. Has a severity and a one-click fix. | | Consent screen | The Google page an employee sees at first sign-in listing the permissions. In Applane it is Internal and carries your own app name. | | OAuth client | The credential, in your GCP project, that the extension signs in with. Web application type, two redirect URIs. | | Licence | A signed token Applane issues to a seat. Valid 72 hours, renewed daily, 7 days of grace offline. | | Cap | The maximum number of active seats. 10 on trial. | | Open and allowlist modes | Who may take a seat: anyone at the domain, or only listed addresses. | | Bot account | `applane-bot@` by convention. A Workspace user that publishes external and public apps so they outlive their builder. | | Admin group | `applane-admins@` by convention. A Google Group made editor on every published app. | | Builders group | `applane-builders@` by convention. The Google Group that gets `roles/aiplatform.user`. | | MCP bridge | The local server that lets Claude Code or Claude Desktop drive the builder through the extension. | | Setup checker | The console's **Run checks** button and the script's `--check` mode. | | Re-push, re-publish | Pushing the platform's files to an app again; repointing the live deployment at the newest version. Two of the advisory fixes. | --- # Changelog > What changed on the Applane docs site, newest first. Source: https://docs.applane.dev/changelog/ ## 2026-08-29 Initial docs. Setup split by audience (Workspace admin, GCP admin, Applane admin, builder), security and data pages, and the reference section. Replaces the single setup tutorial that lived on applane.dev.