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

# Isolation

> How SynapsAI Cloud isolates models on shared GPU infrastructure through sandboxing, filesystem boundaries, network controls, and resource reservations

SynapsAI Cloud runs on **shared, multi-tenant GPU infrastructure**. Multiple models may run on the same physical GPUs. Isolation is enforced through sandboxing, filesystem boundaries, network restrictions, and reserved compute resources — not through dedicated hardware per deployment.

## Sandbox environment

Every model runs inside a **sandboxed execution environment** with strict boundaries on what the process can reach. This is not limited to network access — it also applies to the **filesystem** and **download paths**.

Within a sandbox, a model process:

* **Cannot access the external network** — both ingress and egress are strictly restricted.
* **Cannot read or write arbitrary filesystem paths** — only the directories and files allocated to that deployment are accessible.
* **Cannot access another model's files** — even when both models belong to the same account or team.

These restrictions apply to all deployments regardless of readiness level or pipeline task.

## Filesystem isolation

Each model deployment has its own isolated filesystem scope:

* Model weights, prepared artifacts, and runtime files are accessible only to that deployment's process.
* A model cannot traverse into another model's storage, download cache, or working directories — including other models you own under the same tenant.
* Filesystem access is enforced at the sandbox level, not only by application-level permissions.

## External content fetching

When an API request requires content from the internet — for example, fetching an image, audio file, or video from a URL — the model process does not reach out directly. Instead:

1. The request is handled by an **internal fetch service**.
2. That service runs in its own **sandboxed environment** with controlled network and filesystem access.
3. Fetched content is passed to the requesting model through internal channels within that model's allowed paths.

This keeps model workloads isolated even when endpoints accept URL-based inputs.

## Process isolation

Workloads are segmented at the **operating system process level**. Each model deployment runs in its own isolated process, preventing one workload from accessing another's memory, execution context, or filesystem.

## Compute isolation

When a model instance is allocated, SynapsAI reserves resources for that instance:

| Resource    | Isolation                                                                           |
| ----------- | ----------------------------------------------------------------------------------- |
| **VRAM**    | Reserved on allocation — your model's GPU memory is not shared with other workloads |
| **RAM**     | Reserved for the model process                                                      |
| **Storage** | Weights and artifacts are stored in paths scoped to that deployment only            |

Resource reservations ensure predictable performance and prevent one deployment from consuming another's allocated capacity.

## What this means for you

* Models **share physical GPUs** but do not share process memory, filesystem access, or network access.
* Each deployment runs in a sandbox that cannot read another model's files — including your own other deployments.
* URL-based inputs are fetched through a separate, sandboxed internal service — not by the model process directly.

For data handling practices beyond isolation, see [Data](/resources/data). For operational security recommendations, see [Security best practices](/guides/security-best-practices).