> For the complete documentation index, see [llms.txt](https://docs.teleskope.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.teleskope.ai/setup/deployment/outpost.md). # Outpost An Outpost is a worker-only Teleskope deployment that runs inside your network. It lets Teleskope scan data sources that your Teleskope environment cannot reach directly, including on-premise SQL databases, SMB file shares, and private filesystems. See [Architecture and Data Flow](/setup/deployment/architecture.md) for the full platform architecture, including cloud and SaaS connectors. ## Security and data flow The Outpost opens connections to your data sources from inside your network. Teleskope does not need an inbound path to the Outpost VM or your source systems. The Outpost connects outbound to your isolated Teleskope environment to receive work and report results. ![SaaS and Outpost architecture: workers read private sources and classify locally; optional remote classification sends content over outbound TLS.](https://2383928706-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgO8NOoWqwRd6MduHoEy7%2Fuploads%2Fgit-blob-0a017d98656e4a1dec20cffb3fd6522c0fcdfbf0%2Fsaas-outpost-architecture.png?alt=media) Classification can run locally on the Outpost. **Remote classification is optional** and must be configured for your deployment: | Mode | Where classification runs | What leaves the Outpost | | -------------------------------- | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Local classification | On the Outpost VM | Resource metadata and classification findings | | Remote classification (optional) | In your isolated Teleskope environment | Content being classified, sent to a customer-specific processing endpoint over TLS, plus resource metadata and findings | When an administrator explicitly requests a preview, the Outpost returns the selected sample's matched context to Observatory. Teleskope confirms the classification and preview mode for your deployment before installation. All source access remains inside your network in both modes. Your databases and file servers do not need to accept inbound connections from Teleskope. ## Prerequisites * A dedicated x86\_64 (amd64) VM running Ubuntu 22.04 LTS or later * Root or passwordless `sudo` access * 4 vCPU and 16 GB RAM minimum, with 32 GB RAM recommended * 100 GB of disk * Working DNS resolution and accurate system time * Network access to the Teleskope endpoints and data sources described below * A time-limited bundle URL from your Teleskope team These compute values are a baseline. Teleskope confirms final sizing from your connector count, data volume, schedule, and classification mode. {% hint style="warning" %} The VM and reachable data-source networks must not overlap the k3s default pod range `10.42.0.0/16` or service range `10.43.0.0/16`. The installer does not currently override these ranges. {% endhint %} ## Network requirements All connections are initiated by the Outpost. No inbound firewall rule is required. ### Teleskope and data-source endpoints | Destination | Port | Required when | Purpose | | --------------------------------------- | ------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | `api.metadata..teleskope.ai` | 443 | All deployments | Scheduling, connector configuration, resource metadata, findings, secrets when configured, and heartbeat | | `api.satellite..teleskope.ai` | 443 | Preview and connection-test jobs are enabled | Job leasing and result delivery | | `processing..teleskope.ai` | 443 or 6380 | Remote classification is enabled | Encrypted classification traffic. Teleskope confirms the port for your deployment. | | Your file servers | 445 | SMB scanning | File share access | | Your database servers | Database port | On-premise SQL scanning | Database access, normally 3306 for MySQL, 5432 for PostgreSQL, or 1433 for SQL Server | | Your EFS mount target | 2049 | EFS scanning | NFS access | Deployments configured to use TCP 443 for control traffic and optional remote classification can cover the Teleskope endpoints with one outbound rule for `*..teleskope.ai` on TCP 443. ### Conditional external endpoints | Destination | Port | Required when | | -------------------------------------------------------------- | ---- | ------------------------------------------------------------ | | Bundle download URL host | 443 | The VM downloads the bundle directly | | Container registries and backing storage supplied by Teleskope | 443 | The bundle does not contain application or k3s system images | | `sqs..amazonaws.com` | 443 | The deployment uses AWS queues | | `secretsmanager..amazonaws.com` | 443 | The deployment retrieves connector secrets directly from AWS | | Ubuntu package mirrors and installer dependencies | 443 | A required tool is absent or GPU installation needs packages | | Datadog intake endpoints supplied by Teleskope | 443 | Datadog monitoring is enabled | Your Teleskope team provides the exact hostnames, region, ports, and conditional requirements for your bundle. Restrict egress to that allowlist after installation. ## Bundle modes The installer detects how images are delivered: | Bundle | Contents | Runtime requirement | | -------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Self-contained | k3s, Helm, k3s system images, and Teleskope application images | A standard no-GPU install does not need a container registry or public package download when the VM already has required base tools. | | Registry-pull | k3s and Helm, without application or k3s system images | The VM pulls images from the registries supplied by Teleskope and needs continuing access to those endpoints. | Teleskope tells you which mode your bundle uses. GPU installation can require additional package repositories in either mode. ## Install 1. Download the bundle. Single-quote the URL because signed URLs can contain `&` characters: ```bash curl -o teleskope-k3s.tar '' ``` You can instead download the file on an approved workstation and transfer it securely to the Outpost VM. 2. Extract the bundle: ```bash tar xf teleskope-k3s.tar cd teleskope-k3s ``` 3. Install a standard remote-classification Outpost: ```bash sudo ./install-k3s.sh --no-gpu ``` Teleskope provides separate instructions when local GPU classification is required. The installer sets up k3s, imports bundled images or configures registry pulls, and starts the Teleskope workers. 4. Verify the node and deployments: ```bash sudo k3s kubectl get nodes sudo k3s kubectl get deployments -n teleskope sudo k3s kubectl get pods -n teleskope ``` The node should report `Ready`. The `crawler`, `crawler-dispatcher`, `scanner`, and `scanner-dispatcher` deployments should report all replicas available. If Datadog is enabled, also run: ```bash sudo k3s kubectl get pods -n datadog ``` 5. Ask your Teleskope administrator to confirm that the Outpost has checked in and run **Test Connection** against an assigned data source. A running pod alone does not prove source connectivity. ## Update Teleskope provides a new time-limited bundle URL for each update. From the existing Outpost bundle directory, run: ```bash sudo ./update.sh '' ``` The helper downloads the new bundle into a temporary directory, extracts it, runs `install-k3s.sh --update`, and removes the temporary files. Scan state and connector configuration remain in your Teleskope environment. ## Monitoring Every Outpost exchanges required product and control-plane data with its Teleskope environment. This includes schedules, connector configuration, resource metadata, findings, job results, and a minimal service heartbeat. Operational telemetry is separate. When Datadog is disabled, the Outpost sends no container logs, application metrics, infrastructure metrics, or Kubernetes events to Teleskope's Datadog account. Worker pods still expose Prometheus endpoints for a collector that you operate inside your environment. See [Telemetry and Monitoring](/setup/deployment/deployments/telemetry-and-monitoring.md) for the optional telemetry controls and data destinations. ## Troubleshooting | Symptom | Cause and fix | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | k3s node not `Ready` | Check `systemctl status k3s` and `journalctl -u k3s -f`. | | `x509: certificate signed by unknown authority` | Confirm system time and install the required CA certificates. | | `dial tcp ...:445: i/o timeout` | The VM cannot reach the file server. Check firewall rules between the Outpost and the target. | | Database Test Connection times out | Confirm the selected Outpost can resolve and reach the database hostname and port. | | Pods show `ImagePullBackOff` | A registry-pull bundle cannot reach or authenticate to one of the supplied registry endpoints. | | Pods run but no work arrives | Confirm the Outpost heartbeat, connector assignment, and schedule in Teleskope. | | Source addresses overlap `10.42.0.0/16` or `10.43.0.0/16` | Contact Teleskope before installation. The current installer does not override the k3s network ranges. | | Pods remain in `CrashLoopBackOff` | Collect diagnostics with `sudo ./debug.sh` and contact your Teleskope team. | For anything else, reach out to your Teleskope representative or email .