> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Tensorlake Images
> The managed tensorlake/* images, what ships in them, and how they behave when you run them.
Tensorlake provides managed images optimized for sandbox workloads. These images are designed for rapid boot and are globally available in every project. By default, creating a sandbox without specifying an image uses `tensorlake/ubuntu-minimal`.
These images are fully self-contained and ready to launch without additional build or registration steps. Custom image builds and imports follow a separate workflow, detailed in [Build and Import Images](/sandboxes/images).
## Available Images
* `tensorlake/ubuntu-minimal` (*default sandbox image*): Minimal Ubuntu, systemd excluded. Recommended for scenarios requiring the lowest cold start latency.
* `tensorlake/ubuntu-systemd`: Ubuntu with systemd included. Required for workloads needing service management, such as Docker or Kubernetes, within the sandbox.
* `tensorlake/debian-minimal`: Base Debian 13, minimal profile.
In environments where desktop automation is enabled, you may also see:
* `tensorlake/ubuntu-vnc`: Desktop-enabled Ubuntu derived from `tensorlake/ubuntu-systemd`, preinstalled with XFCE, TigerVNC, and Firefox. Intended for browser automation and interactive desktop workloads. See [Computer Use](/sandboxes/computer-use) for more details.
Launch a sandbox from any of them by name:
```bash theme={null}
tl sbx create --image tensorlake/ubuntu-systemd
```
```python theme={null}
from tensorlake.sandbox import Sandbox
sandbox = Sandbox.create(image="tensorlake/ubuntu-systemd")
```
```typescript theme={null}
import { Sandbox } from "tensorlake";
const sandbox = await Sandbox.create({ image: "tensorlake/ubuntu-systemd" });
```
## Default User and Working Directory
By default, `tensorlake/*` images execute commands as `tl-user` (UID `1000`, home `/home/tl-user`), a non-root user with passwordless sudo. Unlike Standard Docker images, which commonly run as root, this configuration enforces user-level isolation. Tools hardcoded to write to root-owned paths such as `/workspace` will encounter `Permission denied` errors. Note: non-interactive commands start from the filesystem root `/`, so relative commands like `touch output.txt` may fail unless run from a writable directory. Interactive [PTY](/sandboxes/pty-sessions) and SSH sessions default to `/home/tl-user`.
To resolve `Permission denied` errors, ensure commands execute from a directory owned by tl-user (e.g., /home/tl-user), or escalate privileges using sudo or --user root. If files are created as root but need to be accessed by tl-user, adjust ownership with chown:
```bash theme={null}
# Run from a writable working directory
# (working_dir in Python, workingDir in TypeScript)
tl sbx exec --workdir /home/tl-user -- touch output.txt
# Escalate with sudo (works in run() too, which always executes as tl-user)
tl sbx exec -- sudo apt-get update
# Or run the whole command as root
tl sbx exec --user root -- mkdir -p /opt/tools
# Make a system path writable for tl-user
tl sbx exec -- bash -c 'sudo mkdir -p /workspace && sudo chown tl-user:tl-user /workspace'
```
If a workload consistently requires a path such as `/workspace`, include its creation and ownership assignment in a custom image build rather than reconfiguring each new sandbox instance:
```dockerfile theme={null}
FROM tensorlake/ubuntu-minimal
RUN mkdir -p /workspace && chown tl-user:tl-user /workspace
WORKDIR /workspace
```
See [Build and Import Images](/sandboxes/images) for how to build and register a custom image like this one.
Many third-party integrations assume root and default their workdir to `/workspace/`. Point them to `/home/tl-user/`, or use a custom image like the one above. For an example, see the [Crabbox guide](/sandboxes/crabbox).
## Python Packages
Tensorlake Ubuntu and Debian images include a system Python installation managed according to PEP 668. Installing packages with `pip` requires `--break-system-packages` flag, unless a virtual environment is used. Omitting this flag results in the externally-managed-environment error.
For ad hoc installation within a running sandbox:
```python theme={null}
sandbox.run(
"python3",
["-m", "pip", "install", "--break-system-packages", "pandas", "pyarrow", "duckdb"],
)
```
```typescript theme={null}
await sandbox.run("python3", {
args: ["-m", "pip", "install", "--break-system-packages", "pandas", "pyarrow", "duckdb"],
});
```
For repeatable installs, put the packages in `requirements.txt` and install them during a custom image build, as shown in [Build and Register an Image](/sandboxes/images#build-and-register-an-image).
Do not sidestep PEP 668 by switching Python versions. `python3.11 -m pip install ...` or another alternate system Python can produce the same `externally-managed-environment` error. Use `--break-system-packages` with the system `python3`, or create an explicit virtual environment.
## Using Tensorlake Images as Build Bases
Any `tensorlake/*` image can be a `FROM` base (`base_image=` in the SDKs). See [Build and Import Images](/sandboxes/images) for the full workflow.
## See Also
Build your own Docker image or import one from a registry and run it in sandboxes.
Drive the XFCE desktop that ships in `tensorlake/ubuntu-vnc`.
Learn which sandbox settings you can override at launch time.