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

# Storage Connection

> The project-level Storage Connection lets Starfort reach your S3 buckets with encrypted access keys and allowed-target scopes (Starfort v1.4 docs)

For Starfort to read sources and write outputs, it needs a way into your storage. That access is registered ahead of time as a **Storage Connection, per project** — without one, batch intake itself is rejected (`S3_CONNECTION_NOT_CONFIGURED` — see [Batch errors](/en/v1.4/api/batch/errors)).

Registration and management happen in the console's settings area, and every registration, change, and deletion is recorded in the [Audit Log](/en/v1.4/admin/audit-log).

## What gets registered

| Item                 | Contents                                                                                  |
| -------------------- | ----------------------------------------------------------------------------------------- |
| **Endpoint details** | An S3-compatible endpoint URL and access credentials (access key / secret)                |
| **Allowed targets**  | An explicit list of readable buckets and paths (prefixes), and writable buckets and paths |

Grant the credentials **least privilege** — read (`GetObject`) on the source paths and write (`PutObject`) on the output paths is all it takes.

## Access keys are encrypted at rest

The secret half of an access key is **stored encrypted** and is never exposed again by any query after registration.

## Allowed-target scopes

A job's two addresses are each checked against the registered allowed targets:

* `src_s3_url` must be inside the allowed **read** scope.
* `tgt_s3_url` must be inside the allowed **write** scope.

If either falls outside the registered scope, intake is rejected and no job is created (`S3_TARGET_NOT_ALLOWED`). Because delegation is narrowed to a minimum at registration time, the credentials can't accidentally be used against some other path.

## Storage types

A Storage Connection has a **type**, and what gets registered differs by type. The skeleton — per-project registration, scope enforcement, Audit Log coverage — is shared by both.

| Item                     | Object storage type                                                  | File storage type                                                             |
| ------------------------ | -------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| **Endpoint details**     | Endpoint address · access keys (encrypted at rest, never re-exposed) | None — an identifier pointing at an area pre-connected to the platform        |
| **Allowed targets**      | Bucket · path prefix · read/write mode                               | Path prefix · read/write mode                                                 |
| **Scope enforcement**    | Addresses outside the registered scope are rejected at intake        | Same                                                                          |
| **Secret protection**    | Applies                                                              | Not applicable — there's no secret to store                                   |
| **Connection readiness** | Registration alone is sufficient                                     | The area must be connected to the platform before registration means anything |
| **Availability**         | Any deployment form                                                  | **Dedicated customer deployments only**                                       |

A job's source and target are **resolved against separate Storage Connections** — the source address is checked against a connection with read scope, the target address against one with write scope, and the two connections may be of different types (e.g. source on object storage, output on file storage).

### What changes with the file storage type

File storage is accessed through an **area pre-connected to the platform** rather than per-request credentials, so the following differ:

* **The connection is a prerequisite.** Registering the integration only means something once the link between the customer environment and the platform is in place; registering without a connection leads to intake rejections.
* **An unreachable integration area is distinguished from a missing source.** A severed connection can look like "an empty path," so the execution layer confirms the area's connectivity before reading the source and before writing the output — and if it isn't connected, fails the job with a reason distinct from a missing source.
* **Outputs are written only to a confirmed-connected area.** A write attempted without a confirmed connection is finalized as a write failure — there is no such thing as a completion without its output.
* **Output file permissions are fixed to pre-agreed values,** because the integration only works if the downstream consumer can read the result files.

Per-verdict output rules and inspection limits are identical regardless of storage type. See [Output rules & limits](/en/v1.4/api/batch/outputs-and-limits).