# Where Octy runs > Octy runs where its knowledge is held: Atlantic-hosted, in the organisation's AWS, Azure or Google Cloud account, on its own servers, or air-gapped on local models, under every deployment profile. Octy™ runs inside the organisation’s deployment of the Atlantic Agentic Engine, in its own cloud account, on its own servers or air-gapped, beside its gateway and indexes. Questions, passages and answers are stored in the deployment. LightHouse™ receives counts, timings and costs. **LightHouse**: in Atlantic's account - **Limits and cost**: the monthly Octy limit, and the cost of its model calls - **Approvals**: the cards Octy raises, approved by a person - **Portal Octy**: answers from the tenant’s LightHouse data Operational telemetry; no content - **Telemetry** (upward): turns, routes, costs, timings and outcomes - **Signed commands** (downward): limits, pauses and releases **Client deployment**: wherever the engine runs - **Own cloud**: AWS, Azure or Google Cloud, in the chosen region - **Own servers**: Docker or Podman, beside the gateway and the knowledge database - **Air-gapped**: no network path out; local models on the organisation’s GPUs - **Atlantic-hosted**: the same engine, in a dedicated account run for the client Octy runs in the client deployment, on the organisation's models. Operational telemetry is the only data sent to LightHouse; an air-gapped deployment sends it by file. ## Where a profile runs Each [Octy profile](/octy/profiles/) runs where its knowledge is held: | Knowledge | Runs on | Reason | | ------------------------------------------------------------------------------ | ------------------------------- | ------------------------------------------------------------------------------- | | The organisation’s knowledge bases, connected sources and uploaded collections | One of the client’s deployments | Content is read in place, in the client’s account. LightHouse does not store it | | The tenant’s LightHouse data | Atlantic-hosted | It is the portal’s own data, read under the person’s role | | Atlantic’s public documentation and published knowledge | Atlantic-hosted | Atlantic’s own material, for Atlantic’s public profiles | In this table, Atlantic-hosted means that LightHouse answers the profile, in Atlantic’s account. An [Atlantic-hosted deployment](/clouds/atlantic-hosted/), run for a client in a dedicated account, counts as one of the client’s deployments. A profile cannot mix knowledge from both places. LightHouse sends a profile to the deployment that runs it as a signed command, or by command file to an air-gapped site, and shows whether the deployment applied it. See [How a change reaches your deployment](/octy/manage/#how-a-change-reaches-your-deployment). ## The deployment matrix | Where | How Octy runs there | Models | Status | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------- | | **AWS** | A private service on the deployment’s load balancer, beside the client stack | Amazon Bedrock or the Claude API, through the gateway | Built | | **Own servers** | The Octy container in the stack LightHouse generates, beside the gateway and the knowledge database. See [On-premises](/clouds/on-premises/) | Any provider the gateway reaches, or a local model | Built | | **Air-gapped** | As on the organisation’s own servers, with no network path out | An open-weight model on the organisation’s NVIDIA GPUs | Built | | **Azure** | The same image on Azure Container Apps, behind the stack’s ingress | Azure AI Foundry, through the gateway | The image runs there; the one-click module is \[Coming] | | **Google Cloud** | The same image on Cloud Run, behind the stack’s ingress | Vertex AI, through the gateway | The image runs there; the one-click module is \[Coming] | | **Atlantic-hosted** | As on AWS, in a dedicated account that Atlantic runs for the client. See [Atlantic-hosted](/clouds/atlantic-hosted/) | As on AWS | Built | In every deployment, Octy holds no provider key. The gateway holds the only model credential, the budgets and the kill switch. The Octy image contains no model SDK. ## Air-gapped, on local models Octy can run with no network path out of the organisation’s environment: - **Local models.** An open-weight model runs on the organisation’s NVIDIA GPUs, served by vLLM, or by NVIDIA NIM under the organisation’s licence, and the gateway calls it on the local network. Prompts and answers remain on the organisation’s machines. See [Self-hosted models](/clouds/on-premises/#self-hosted-models). - **Local knowledge.** Documents are indexed into the knowledge database in the organisation’s environment. The embedding model that builds the meaning index runs there too. - **Telemetry by file.** The deployment keeps its telemetry as signed, numbered bundle files, which an operator carries to LightHouse. Commands come back in a signed command file. See [Air-gapped operation](/clouds/on-premises/#air-gapped-operation). With Octy profiles, an air-gapped site operates as follows: - **Profiles by command file.** A change to a profile goes into the next command file, and the profile shows as waiting for it in LightHouse. The site applies the file, and the change shows as applied once the site’s next telemetry bundle is imported. - **Local models only.** The router’s candidates are the models served on the site. A profile that names any other model is refused by the deployment. - **Question text on site.** LightHouse shows counts, outcomes, costs and hashed clusters of equal questions from the imported bundles. The question text is on the site’s own Octy insights page, behind the site’s sign-in. See [Question insights](/octy/evidence/#question-insights). - **Receipts signed on site.** Answers are signed with the deployment’s own key and can be verified without a call to Atlantic. ## Deployment profiles Octy works under each [deployment profile](/concepts/deployment-profiles/): | Profile | What it means for Octy | | ------------- | -------------------------------------------------------------------------------------------------------------- | | **Always-on** | Answers at once, at any hour | | **Ephemeral** | Services sleep when idle. The first question after a quiet period wakes Octy, and is answered once it is ready | | **Scheduled** | Warm in the configured wake window, such as working hours; outside it, woken on demand as under ephemeral | While a deployment wakes, the caller receives a notice that Octy is starting and the time after which to ask again. The website widget shows the notice and asks again automatically. On the organisation’s own servers, Octy runs continuously. The [cost analysis](/octy/costs/#cost-analysis-per-profile) shows the time of the first answer after a wake for each profile. For Octy used only in working hours, the scheduled profile answers immediately during the wake window and costs less than always-on, estimated. See [Estimated savings against always-on](/concepts/deployment-profiles/#estimated-savings-against-always-on). ## Residency Octy keeps its inference in the region its deployment names. Cross-region model profiles are refused unless the deployment allows them, and the gateway’s policy refuses them again. Documents, indexes and conversations remain in the organisation’s account. See [Data sovereignty](/data-sovereignty/) and [Regions](/data-sovereignty/regions/). Source: https://docs.atlanticagenticlabs.com/octy/where-it-runs/