> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Run Compute against on-premises data
description: >-
  Stage an immutable copy on your side and exchange it outbound. Private-network
  requirements and allowlists are documented; fetching an arbitrary URL is not a
  Compute feature.
route: /docs/compute/integrations/on-premises
page_id: docs-compute-integrations-on-premises
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Platform and network engineers exchanging on-premises data with Compute
voice: D
reader_question: How do I run Compute over data that lives inside my own network?
primary_action: Stage an immutable copy and request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-on-premises-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## What this connects

Data that lives inside your own network, exchanged outbound by you. You stage an immutable copy, then push or authorize the read; Lithi never reaches inward to find it.

The conformance level for that exchange is `import_compatible`, backed by a published conformance matrix for the formats read. There is no inbound connector, agent or tunnel into your network.

## Bind an exact input

Stage before you submit. Copy the exact rows or files you want into a staging location you control, stop writing to it, then take the digest of what you staged.

```json
"snapshot": {
  "version_id": "<the staging write identity you recorded>",
  "content_sha256": "<the digest of those exact bytes>"
}
```

Staging is what makes an internal system safe to work from. A live database, a shared drive under active use, or a mount another process can write to is not a frozen input. See [how to pin a snapshot that cannot change](/docs/compute/inputs/immutable-snapshots).

Where the data must not leave your premises at all, upload only what the workflow needs, or reduce the copy before staging it.

## Credentials

`input.credential_ref` names a credential you registered as a reference, scoped to reading the staging location and nothing more. Register it, test it, read it back, and revoke it when the work ends.

No internal system credential belongs in a work request. Directory passwords, database logins, certificate private keys and VPN secrets stay inside your network, and none of them has a field in the request.

## Formats and limits

Outbound is the direction that works. Your side opens the connection, or you authorize a read against a location you already publish.

Write down what your network actually requires before the first run:

- The outbound destinations your staging tool must reach, resolved from the destination and source registrations you created, not guessed.
- Which proxy the upload passes through, and whether it inspects or rewrites bodies.
- Your egress allowlist entries and who reviews them.
- Your own retention rule for the staging location, so a copy is not left behind after the run.

Where an inbound read is permitted, restrict it to the exact staged location and revoke the credential afterwards. The maximum item count for a workflow is stated on its descriptor and repeated on your quote.

## Commit the output

Results are written to result storage encrypted, and you hold the download authority. Bring them back the same way you sent data out: your side pulls.

`result-manifest.json` is written last and is the only complete-bundle marker. Verify the download against the manifest counts and digests before you load anything into an internal system.

Where you registered an internal destination that Lithi may write to, delivery is verified before it is committed, moving through `WRITTEN_UNVERIFIED`, `VERIFIED`, then `COMMITTED`, and reporting `WRITE_FAILED` or `COMMIT_CONFLICT` with a next action rather than overwriting. See [how credentials and federation work](/docs/compute/security/credentials-and-federation).

## What is not supported

Compute does not fetch a URL you hand it. Arbitrary URL fetching is not a feature, and no adapter accepts one.

Outside the adapter:

- Inbound access into your network, including a hosted agent, tunnel or reverse connection.
- Reading a database, file share or internal service directly.
- Discovering data by crawling a path, a host or a link you supply.
- Any credential granting more than the staged location you named.

If a delivery to an internal destination fails, the state names the reason and a next action. Fix the target or the allowlist entry, then retry the delivery. The job does not rerun, and you are not charged for a second run of completed work.