Open WebUI 0.13.0 Tutorial: Build a Local AI Coding Workspace with Browser and Git

Updated: November 5, 2026. A local model can explain a code change, but a useful development assistant also needs somewhere safe to inspect files, run tests, start a server and check the result. Open WebUI 0.13.0 brings a tabbed workspace for chat, files, terminals, browser previews and Git; Open Terminal supplies the isolated execution environment behind those actions.

This guide builds that workflow with Docker Compose. You will connect a model provider, attach an Open Terminal workspace, create a small Git project, ask the model to make a change, review the diff and open the running app in the new Browser tab.

What changed in the November 2026 releases?

Open WebUI v0.13.0 was released on November 3, 2026. Its release notes describe a tabbed workspace for files, multiple terminal sessions, artifacts, previews, voice calls and comments; a Browser tab for websites and local development servers; a Desktop tab backed by a connected Open Terminal; and a Git panel for diffs, staging, commits, branches and worktrees. The release also adds MCP Apps in chat, side chats and multi-model sub-agents. These are confirmed release-note items, not independent performance claims: Open WebUI v0.13.0 release notes.

Open Terminal v0.16.1 was released on November 4, 2026. Its listed fixes address a large-folder file watcher that could make the terminal unresponsive and missing emoji/country-flag fonts in the Browser tab's default Docker image. The version is marked latest on the project's release page: Open Terminal v0.16.1 release.

The combination is useful because the chat is no longer just a place to receive code snippets. With a compatible terminal and tool-calling model, an agent can work inside a bounded project directory, run commands, report results and let you inspect the output in the same conversation.

Who this guide is for

• Developers who want a self-hosted AI coding workspace rather than another cloud IDE.
• People already using Ollama or another local/OpenAI-compatible model server.
• Small teams that need a browser-based way to review AI-generated files and Git changes.
• Administrators who want to understand the boundary between Open WebUI permissions and terminal execution.

Prerequisites

• Docker Engine and Docker Compose v2.
• A machine with enough disk space for the Open Terminal image and project dependencies. The default image is feature-rich and considerably larger than its slim variant.
• An Open WebUI administrator account.
• A model provider reachable from the Open WebUI container. For a local-first setup, this can be Ollama on the host or another local OpenAI-compatible server.
• A model that can use native function/tool calling reliably. Tool support varies by model and quantization; a model that can answer questions well may still struggle with multi-step terminal work.
• A disposable project directory or Git repository for the first test. Do not begin with a production checkout or a directory containing secrets.

1. Create a deployment directory and secrets

Make a new folder for this Compose project. Keep the terminal API key in a file rather than writing it into shell history or committing it to Git.

mkdir -p openwebui-workspace/secrets
cd openwebui-workspace

openssl rand -hex 32 > secrets/terminal_api_key.txt
printf 'WEBUI_SECRET_KEY=%s\n' "$(openssl rand -hex 32)" > .env
chmod 600 secrets/terminal_api_key.txt .env

The terminal key will be mounted into the container as a Docker secret. You will also enter that same key in Open WebUI's admin connection form. Treat it as a password: anyone who can reach the terminal service and present the key can run commands and read or modify files inside its workspace.

2. Run Open WebUI and Open Terminal on a private Compose network

Create docker-compose.yml in the deployment directory:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    volumes:
      - webui-data:/app/backend/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY}

  open-terminal:
    image: ghcr.io/open-webui/open-terminal:0.16.1
    container_name: open-terminal
    restart: unless-stopped
    volumes:
      - terminal-data:/home/user
    secrets:
      - terminal_api_key
    environment:
      OPEN_TERMINAL_API_KEY_FILE: /run/secrets/terminal_api_key
    mem_limit: 2g
    cpus: 2.0

volumes:
  webui-data:
  terminal-data:

secrets:
  terminal_api_key:
    file: ./secrets/terminal_api_key.txt

Important networking detail: there is deliberately no ports: mapping on open-terminal. Both services join Compose's default network, so Open WebUI can reach the terminal at http://open-terminal:8000 without publishing the command-execution API to your LAN or the public internet. The Open WebUI port is published on host port 3000 for this local example; put it behind your normal HTTPS/private-access layer before sharing it.

The Open WebUI image uses the project's documented main channel, which is a moving tag. At the time of this guide, the latest release is v0.13.0. If you need a reproducible deployment, record and pin the exact image digest from the official package page rather than assuming main will always refer to the same build. The Open Terminal image is pinned to the verified 0.16.1 tag. See the Open Terminal container package for available tags and digests.

Start the services and inspect their status:

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 open-webui open-terminal

Open http://localhost:3000 and create the first administrator account if this is a new installation. The named volumes preserve Open WebUI's database and the terminal workspace across container recreation.

For a local Ollama instance running on the host, the Compose file includes host.docker.internal resolution. Open WebUI's provider settings can use http://host.docker.internal:11434. The Ollama process must be reachable from the container; if you change its listener from loopback, restrict the host firewall so the API is not exposed to untrusted networks. If your model server is another container, use its Compose service name and a shared private network instead.

3. Connect a local model provider

1. Open your profile menu, then Settings → Admin → Connections.
2. For Ollama on the host, check the Ollama connection at http://host.docker.internal:11434. For a different local server, add the matching Ollama or OpenAI-compatible connection URL and authentication details.
3. Save the connection and confirm that the intended model appears in the model selector.
4. Choose a model with native tool-calling support. Avoid assuming that every quantized build has the same tool-call reliability.

Open WebUI's current documentation describes Native function calling as the default. Check the model under Workspace → Models and make sure it has not been switched to Legacy mode. The Open Terminal documentation warns that multi-step computer workflows are demanding: small models can emit malformed calls or fail to continue after observing command output. If the agent repeatedly ignores the terminal, test a stronger tool-capable model before changing the terminal configuration.

References: Open WebUI quick start and provider connections · Native vs. Legacy tool calling.

4. Add Open Terminal through the admin integration

Use the admin-configured integration, not a personal browser-side connection. The admin connection keeps the terminal API key on the Open WebUI server and allows access to be controlled centrally.

1. In Open WebUI, open Settings → Admin → Integrations.
2. Find the dedicated Open Terminal section. Do not add this endpoint as an ordinary External Tool or Tool Server; the dedicated integration provides the file browser and terminal workspace.
3. Click + and enter http://open-terminal:8000 as the URL.
4. Open secrets/terminal_api_key.txt on the server and paste its value into the API Key field. Leave the authentication type as Bearer.
5. Save the connection, make sure its toggle is enabled, and use the access-control button to limit it to the intended user groups.
6. Start a chat and click the terminal/cloud control beside the message input. Select the configured terminal under System.

To verify the service-to-service network path from the Open WebUI container, run:

docker compose exec open-webui \
  curl -fsS http://open-terminal:8000/health

A healthy response is {"status":"ok"}. If the request fails, check the Compose service names and logs before changing firewall rules. The official connection guide explains why localhost is wrong when the two services are in separate containers: inside a container, localhost points back to that same container.

Source: Connecting Open Terminal to Open WebUI.

5. Prepare a disposable Git workspace

Use a clean project directory for the first run. You can create it from a New Terminal tab or ask the model to create it after selecting the terminal. For a manual starting point:

mkdir -p ~/workspace/owui-demo
cd ~/workspace/owui-demo
git init

Configure a Git author for this repository if you intend to make a local commit:

git config user.name "Your Name"
git config user.email "[email protected]"

Now ask the model:

Inspect only the current repository. First report the files and Git status. Create a small responsive landing page in this directory. Do not access parent directories, environment files, SSH keys or unrelated projects. Do not run sudo, delete existing files, install global packages, commit or push. Show me the files you intend to change before editing.

This instruction is not a security boundary—the model can misunderstand it. The actual boundary is the terminal container, its mounted volume, the API key and the permissions you configure. Start with a disposable repository and review every command that can modify data.

6. Review changes in the new Git panel

Open the Files tab in the workspace side panel and navigate into the repository. When the selected folder is inside a Git repository, a Git panel appears at the bottom of the side panel on a compatible terminal. The feature requires tool servers to be enabled and a terminal version that supports Git.

Use the panel to:

• Inspect unified or split diffs before accepting changes.
• Stage only the files you have reviewed; unstage or discard changes that should not be kept.
• Review commit history and switch branches or worktrees when needed.
• Make a local commit after checking the staged diff. Push only after you have verified the branch and remote.

The Git panel is a review surface, not proof that generated code is correct. Run the project's tests and inspect the actual diff. If a Git panel does not appear, confirm that the selected folder is a repository, the terminal has Git installed, and tool servers are enabled.

Source: Open WebUI File Browser and Git panel documentation.

7. Preview the project in the Browser tab

Ask the model to start a development server from the project directory. For a simple static HTML project, the command can be:

python -m http.server 3000 --bind 0.0.0.0

Open the workspace + menu and add a Browser tab. The start page lists ports detected by the terminal. Choose port 3000 to preview the site.

• Proxy mode is suitable for viewing a local development server inside Open WebUI.
• Chrome mode provides a shared browser session that the model can interact with for browser automation and web-app testing. It requires browser-session support and Chrome/Chromium in the selected terminal.

Open Terminal monitors ports started in its workspace and reports them to Open WebUI. The Browser tab proxies the preview through Open WebUI, so you do not need to publish every development-server port separately. Open multiple Browser tabs if the project has separate frontend and backend servers.

Use a prompt such as:

Open the local preview, check the page at desktop and mobile widths, and report any visible layout or console issues. Do not submit forms, contact external services or make purchases. Suggest fixes first, then wait for my approval before changing files.

Source: Build and preview websites with Open Terminal.

8. Optional: use the Desktop tab

Open WebUI 0.13.0 also adds a Desktop tab for a connected terminal that has desktop support enabled. It lets you view and control the terminal-provided desktop with mouse, keyboard and clipboard; audio depends on the terminal platform and version. Open Terminal 0.16.0 added audio playback for the Linux Desktop tab, while its release notes say sound sharing is not available for native Mac or Windows desktops. This is separate from the Open WebUI Desktop application, which is a separately installed app for running Open WebUI locally.

Use the Desktop tab only when a workflow genuinely needs a graphical application. For ordinary web development, the Browser preview and Git diff are usually easier to review.

9. Give the agent a repeatable project brief

Once the basic loop works, keep project instructions in a repository-level AGENTS.md file. Open WebUI's terminal integration can include that file as workspace context when a terminal is selected. Keep it concise and non-secret. A useful starter file might say:

# Project rules
- Read the README and package scripts before changing code.
- Run the smallest relevant test after each change.
- Never edit .env files, credentials or deployment secrets.
- Do not run sudo or install global packages.
- Show a diff before committing.
- Do not push branches or deploy without explicit approval.
- Report commands that failed and do not claim tests passed unless they ran.

For reusable workflows, see the existing GyanAangan guide to Open WebUI Skills. If you want to keep the coding agent inside VS Code instead of a browser workspace, compare this workflow with Continue + Ollama in VS Code.

Expected result

• Open WebUI remains the chat and model-control layer.
• Open Terminal runs commands in its own container and persists the workspace in a named volume.
• The Files tab shows project files and previews.
• The Git panel lets you inspect and stage changes from a repository.
• The Browser tab previews a development server without publishing its port separately.
• The model can use the terminal only when its tool calls work and the selected user is allowed to access the terminal connection.

Security and privacy checklist

• Keep port 8000 private. Do not publish the Open Terminal API port on a public interface. In the Compose example, only Open WebUI has a host port mapping.
• Use Docker isolation. Do not switch to bare-metal execution unless you intentionally want commands to run with your host user's permissions.
• Do not mount the Docker socket. Giving the terminal access to /var/run/docker.sock is effectively giving it control of the host's Docker daemon and can lead to host-level compromise.
• Mount only the workspace. Avoid mounting your home directory, SSH folder, cloud credentials or production configuration files into the terminal.
• Keep the API key secret. Use Docker secrets or a protected config file, rotate the key if exposed, and prefer the admin-configured connection so it stays server-side.
• Limit CPU and memory. Tune resource limits for your machine and the workloads you allow.
• Restrict network egress. If the agent needs package downloads, configure the documented allowed-domain list instead of allowing unnecessary outbound access.
• Review untrusted input. A README, issue, web page or dependency script can contain prompt-injection instructions. Treat repository text as data, not authority. Require approval for destructive commands, credentials access, commits, pushes and deployments.
• Do not confuse a shared container with tenant isolation. A shared Open Terminal container is suitable only for a trusted environment. For users who must be isolated from one another, use a per-user execution boundary rather than relying on separate home folders in one container.

Read the project's Open Terminal security guidance before connecting it to a shared or internet-accessible deployment.

Troubleshooting

Open Terminal does not appear in the picker

Check that the connection is enabled, the user or group has access, and the terminal is configured under Settings → Admin → Integrations → Open Terminal. If the section is disabled, check whether ENABLE_TOOL_SERVERS has been set to False.

Connection fails with a timeout

From Compose, use http://open-terminal:8000, not localhost. Then test the internal health endpoint with the command in Step 4 and inspect docker compose logs open-terminal.

The model answers but never runs a command

Confirm that the terminal is selected in the chat, the connection toggle is on, and the model uses Native function calling rather than Legacy. Try a model with stronger tool-calling behavior. The terminal being connected does not guarantee every model can operate it reliably.

The Browser tab or Chrome mode is missing

Update Open WebUI to v0.13.0 or newer and Open Terminal to a release with browser-session support. Chrome mode needs Chrome/Chromium in the terminal image; Proxy mode is for previews and does not provide the same interactive browser automation surface.

The Git panel is missing

Open a folder inside a Git repository, confirm Git is installed in the selected terminal, and ensure tool servers are enabled. A folder outside a repository does not have repository diffs to display.

A large directory makes the terminal slow

Open Terminal v0.16.1 includes a fix for watching large folders outside Git repositories. Update the terminal image and avoid selecting filesystem roots or broad host mounts as a project workspace.

Trade-offs and limitations

• This is an agent workspace, not a full replacement for a native IDE. You still need code review, tests, debugging discipline and a deployment process.
• Local inference does not automatically mean good agent behavior. Tool-calling quality, context size, available RAM/VRAM and model latency affect the workflow.
• The Open WebUI main image is a moving tag. Pin a digest for reproducible production deployments and test upgrades against a backup first.
• The default Open Terminal image is large because it includes a broad set of developer and document tools. Slim variants reduce image size but do not have the same runtime package-install capabilities.
• Chrome and Desktop features depend on the selected terminal image and platform. A visible tab does not mean every computer-control capability is available on every host.
• Docker limits reduce blast radius; they do not make arbitrary model-generated commands safe.

Frequently asked questions

Can this run fully locally?

Yes, if Open WebUI is connected only to a local model server such as Ollama and you do not configure cloud providers. Model downloads, package installation and browser access may still use the network unless you restrict or disable them.

Does the Browser tab expose my development server to the internet?

The documented preview flow proxies the terminal's detected port through Open WebUI. It does not require you to publish each development port separately. Keep Open WebUI itself behind authentication and a private or properly secured access layer.

Can I use LM Studio instead of Ollama?

Open WebUI supports OpenAI-compatible API connections. If your LM Studio server exposes a compatible endpoint and the selected model supports the required tool calls, you can configure it as a provider. Compatibility depends on the model's tool-call format and the runtime implementation.

Is one Open Terminal container safe for multiple unrelated users?

Do not assume so. Separate directories or Linux accounts inside one shared container are not a strong security boundary. Use a per-user container/orchestrator design when users must not access one another's files or processes.

Is the Desktop tab the same as Open WebUI Desktop?

No. The Desktop tab displays a desktop supplied by the connected Open Terminal. Open WebUI Desktop is a separately installed application for running Open WebUI on macOS, Windows or Linux.

Official sources and further reading

• Open WebUI v0.13.0 release notes — released November 3, 2026; tabbed workspace, Browser/Desktop tabs, Git panel, MCP Apps and security-fix notice.
• Open Terminal v0.16.1 release notes — released November 4, 2026; large-folder responsiveness and Browser-tab font fixes.
• Open Terminal installation — Docker, Compose and bare-metal options.
• Connecting Open Terminal to Open WebUI — admin integration, API key handling and Native function calling.
• Open Terminal security best practices — Docker isolation, API keys, resource limits and network controls.
• File Browser and Git panel — repository diffs, staging, commits and branches.
• Build and preview websites — detected ports and Browser-tab workflow.
• Open Terminal container images — available tags and image digests.

Related GyanAangan guides

• Open WebUI Skills: create and secure reusable AI workflows.
• Open WebUI Skills not loading: Open Terminal compatibility and troubleshooting.
• Continue + Ollama in VS Code: local chat, edits and autocomplete.
• Open WebUI + vLLM integration guide.

Verification note: This tutorial was prepared from the official release notes, documentation and container-package metadata checked on November 5, 2026. The Compose configuration and commands are documentation-based examples; they were not executed against a live deployment for this article. Verify the current image digest, model tool-calling behavior and terminal feature support in your own environment before using the workflow with valuable code or data.