Introduction: The Power and Risk of AI Code Execution

The launch of ChatGPT's Advanced Data Analysis (formerly Code Interpreter) revolutionized how we interact with LLMs. By allowing the AI to write and execute Python code in real-time, it transformed simple text generation into complex data analysis, mathematical modeling, and automated file manipulation. However, for enterprises and privacy-conscious developers, passing proprietary code, sensitive financial spreadsheets, or customer data to third-party cloud environments poses significant compliance and security risks.

What if you could replicate this exact capability on your own infrastructure? Self-hosting an AI Code Interpreter gives you absolute control over your data pipelines. But executing untrusted, AI-generated code on your own Virtual Private Server (VPS) is inherently dangerous. A hallucinating or malicious AI could accidentally execute command injections like rm -rf / or scan your internal network. This comprehensive guide details how to build a highly secure, sandboxed Python code execution environment on a VPS, mirroring the seamless user experience of ChatGPT while maintaining enterprise-grade security.

The Core Challenge: Why Standard Docker Isn't Enough

When engineering a self-hosted Code Interpreter, the instinct for many developers is to spin up a standard Docker container and let the LLM talk to it via an API. While Docker provides process isolation, it shares the host machine's OS kernel. If a vulnerability exists within the Linux kernel, a poorly generated Python script could achieve a container escape, compromising your entire VPS host.

To build a truly resilient sandbox, we must adopt a layered defense strategy. Our target architecture relies on three primary pillars:

Runtime Isolation: Replacing standard Docker runtimes (runc) with a secure, sandboxed container runtime like Google's gVisor or Amazon's Firecracker microVMs.
Network Isolation: Blocking all outbound internet access from the execution environment to prevent data exfiltration and side-channel attacks.
Resource Constraints: Strictly limiting CPU, memory, and disk I/O to prevent Denial of Service (DoS) attacks caused by infinite loops or memory leaks.

Architectural Overview: The Component Stack

To implement this setup seamlessly, we will integrate several robust open-source components:

Frontend UI & Orchestration (Open WebUI / LibreChat): Acts as the interface for users, sending prompts to the LLM and detecting when code execution blocks are required.
Execution Gateway (Jupyter Kernel Gateway): Exposes a secure REST API and WebSocket interface to spawn, manage, and interact with individual Python kernels.
Sandboxed Environment (Docker + gVisor): The actual infrastructure where the Jupyter kernels spin up and execute code, wrapped inside a hardened kernel abstraction layer.

Step-by-Step Implementation Guide

Step 1: Hardening the VPS with gVisor

First, we need to install gVisor on your VPS. gVisor intercepts system calls from the application and handles them in a user-space kernel (written in Go), meaning the container never talks directly to the host Linux kernel.

Note: This guide assumes you are running Ubuntu 22.04 LTS or 24.04 LTS on a VPS with root or sudo access.

Run the following commands to install the gVisor repository and its runsc component:

curl -fsSL [https://gvisor.dev/archive.key](https://gvisor.dev/archive.key) | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] [https://gvisor.dev/apt](https://gvisor.dev/apt) release main" | sudo tee /etc/apt/sources.list.d/gvisor.list
sudo apt-get update && sudo apt-get install -y runsc

Next, register gVisor as a Docker runtime by updating your /etc/docker/daemon.json file. If the file doesn't exist, create it:

{
  "runtimes": {
    "runsc": {
      "path": "/usr/bin/runsc"
    }
  }
}

Restart the Docker service to apply the new runtime configuration: sudo systemctl restart docker.

Step 2: Configuring the Sandbox Network and Resource Limits

To prevent the AI from downloading external packages dynamically (which could contain malware) or sending data back to a command-and-control server, we must disable network access for the execution container. We will define this strictly within a docker-compose.yml file, enforcing strict resource quotas to prevent the host from running out of memory.

Create a dedicated directory and add the following configuration:

version: '3.8'

services:
  code_interpreter_backend:
    image: jupyter/base-notebook:latest
    runtime: runsc
    command: jupyter kernelgateway --KernelGatewayApp.ip=0.0.0.0 --KernelGatewayApp.port=8888 --AuthToken.sha1='your_hashed_password'
    networks:
      - internal_only
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    volumes:
      - ./shared_data:/home/jovyan/work
    restart: always

networks:
  internal_only:
    internal: true

By explicitly setting internal: true, the container can talk to your UI backend (if placed in the same network context) but cannot route any traffic to the public WAN. The runtime: runsc directive ensures gVisor handles the execution isolation.

Step 3: Connecting the Frontend LLM Interface

Modern open-source LLM UI platforms like Open WebUI natively support Code Interpreter workflows via connections to Jupyter endpoints. To connect Open WebUI to your newly sandboxed Jupyter Kernel Gateway:

Navigate to the Admin Settings within your Open WebUI dashboard.
Locate the Images & Code Execution or Code Interpreter tab.
Enable the external execution feature and input your backend URL (e.g., http://code_interpreter_backend:8888) along with the authentication token generated during Step 2.

Once saved, when you prompt your local model (such as Llama 3 or Mistral) with a prompt like "Plot the sales trend from this CSV file," the UI will securely pipe the generated Python code block to your gVisor-isolated Jupyter instance, execute it, and return the visual chart directly inside your chat window.

Enterprise Best Practices for Post-Deployment Maintenance

Building the infrastructure is only half the battle. To guarantee long-term security and optimal performance, implement these operational practices:

Stateless Ephemerality: Configure automated cron jobs to wipe and recreate the Python workspace directories every hour. This ensures that even if temporary state accumulation occurs, files do not persist indefinitely.
Pre-baked Dependencies: Since the sandbox lacks internet access, pre-install all required data science libraries (such as pandas, numpy, matplotlib, scikit-learn, and seaborn) within a custom Dockerfile instead of relying on runtime installations.
Audit Logging: Stream all console outputs and kernel logs from the Jupyter Gateway container to a central log manager. This creates a concrete audit trail of exactly what scripts the AI models generated and attempted to run.

Conclusion

By shifting from standard cloud ecosystems to a self-hosted, gVisor-hardened VPS architecture, you successfully capture the massive productivity boosts of ChatGPT's Advanced Data Analysis without compromising corporate security boundaries or data compliance regulations. Your data remains strictly local, your execution environment is completely unprivileged, and your AI stack becomes robustly production-ready.

Self-Hosting a Secure 'AI Code Interpreter' on Your VPS: A Guide to Sandboxed Python Execution