open-webui

Self-host Open WebUI today, for free: pip install open-webui open-webui serve You'll need Python 3.11 or 3.12. Or use the one-line Docker command in the guide. View the source: open-webui/open-webui Get started, and tell us what you build: openwebui.com

@fight_hrx @Youssofal_ @LinusTech With a 5090 and Ollama already running, the easiest next step is Open WebUI: one Docker command gives you a ChatGPT-style UI on top of your Ollama models, with docs/RAG built in. No coding needed. open-webui/open-webui What do you want it to do first?

Open WebUI 0.13.0: a TABBED WORKSPACE with terminals, files, GIT, a BROWSER and a DESKTOP you share with the model, plus SIDE CHATS, COMMENTS, MCP APPS and sub-agents on OTHER MODELS. 0.13.0 brings 48 changelog entries from 193 commits: 26 features, 15 fixes and 7 changes. It contains security fixes and a database migration, so back up and update soon. Your chat gets a workspace. The Tabs button at the top of a chat opens tabs for files, terminals, artifacts, previews, voice calls and comments. Add them from the + menu, drag to reorder and save new files straight into the terminal. On large screens the tabs can go full width, with the chat as its own tab. - Git panel: diffs, stage, discard, commit, branches, worktrees, push, pull, history and GitHub pull requests when the terminal's folder is a repository. - Git, open ports and running processes update live on terminals that support it. - File sizes in previews, sort by date added and a 3D viewer for GLB, glTF, STL, OBJ and PLY. A desktop and a browser, shared with the model. - Desktop tab: your Open Terminal's desktop with mouse, keyboard, clipboard and audio where available. The model takes screenshots, clicks, types and scrolls while you watch, and you step in when needed, for example to type a password. - Browser tab: websites and local dev servers beside the chat, with several tabs and a mobile viewport. In Chrome mode you and the model share one session to navigate, fill in forms and test the apps it builds. - Update Open Terminal to 0.16.0. Its Docker image ships a Linux desktop with LibreOffice and Chromium. Run directly on a Mac or Windows PC, it shows that screen (on a Mac, grant Screen Recording and Accessibility). Also new: - Side chats: /side, /btw or Side chat opens a temporary conversation with the chat as context. It disappears when you close the tab. For admins and users with the new Allow Side Chat permission (off by default). - Comments (ENABLE_COMMENTS, off by default): replies, reactions and mentions on chats, notes, models, knowledge bases, prompts, skills and tools, also on a selected passage. /comments opens them in a tab. - Inbox (ENABLE_NOTIFICATIONS, on by default): comments, replies, mentions, failed automations and upcoming events, with an unread count. - MCP Apps show in the chat in a sandboxed frame. Every tool call they make waits for your confirmation. - Sub-agents can run on other models, picked in the model editor. - Models with native function calling can create private Python tools on request (Tool Creation, per model). - On and off switch for tools. A switched-off tool cannot run in any chat. - "Waiting for approval" marker on sidebar chats. - Compaction can reuse the prompt cache when the same model writes the summary, which can lower its cost. - Knowledge base limits for file count, file size and files per upload (KNOWLEDGE_MAX_FILE_COUNT, KNOWLEDGE_MAX_FILE_SIZE, KNOWLEDGE_MAX_UPLOAD_COUNT), plus per knowledge base limits set by the owner. - {{USER_ROLE}} prompt variable. - Generate a title from the top bar, side panels on tablets, movable blocks and code Copy buttons in notes, more PowerPoint chart types. - Accessibility: names for every window, field, setting and icon button, and keyboard access to tool approvals, notifications, table sorting, sidebar resizing and the calendar. Open WebUI Desktop 0.1.4 (separate app) now focuses on running Open WebUI locally, with optional llama.cpp models, a slimmer interface, searchable settings, startup logs and start to tray. It no longer switches between remote servers, bundles Open Terminal or has the Spotlight and voice overlays. github.com/open-webui/desktop/releases/tag/v0.1.4 Fixes: - New chats from the home page sync with the server again, so removed files stay removed and shared chat owners get Regenerate back. - Temporary Chat on a folder page keeps you in the folder. - Interrupting the model in a realtime voice call no longer ends the call. - Temporary chat replies keep arriving after a reconnect. - The home page and folders pick the model and apply link settings again, and drafts come back. - The Chat Completions API streams correctly from models on the Responses API. - Context usage is more accurate during long agent runs. - Photos dragged from macOS Photos are recognized as images. - Preview opens nested code blocks, channel reactions show who reacted, and thread replies get focus. - OAuth providers load their saved settings at startup. Security: this release contains security fixes. The advisories follow once their CVEs are assigned. Before you upgrade: - Database migration: back up first. Multi-worker and multi-server setups must update all instances at once. - Chat files, valves, system prompt and parameters moved from Controls at the top to the model controls menu next to the input. The top button now opens the tabs. Overview moved to the chat menu. - The tool-call limit is now 1024 rounds. Set CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS to 256 to keep the old one. - Sub-agent limits (SUBAGENTS_MAX_*) now default to no limit. - The "Retrieval Content process failed" notification is gone. Full changelog: github.com/open-webui/open-webui/releases/tag/v0.…

Open WebUI 能把本地 Ollama 和云端模型接进同一个聊天界面，还能上传文档问答。 用 Docker 部署，记得挂载数据卷。官方特别提醒：数据库不持久化，重建容器可能连聊天记录一起丢掉。模型仍要另接，装好界面不等于装好模型。 open-webui/open-webui t.co

webUIはこれを使ってごにょごにょやって、ローカルに開放すればMacの外からwebブラウザ経由で使えます » GitHub - open-webui/desktop: Open WebUI Desktop 🌐 · GitHub open-webui/desktop

I Ran AI Offline for 7 Days. Was It Worth It? I typed "Olá" into my own offline chat and waited. Twenty-four seconds later, the model said hello back. The model wasn't broken and the hardware wasn't dead. The slowness came from two settings I didn't know were on, and finding them taught me more about running AI offline than any benchmark chart. Here's the setup. I bought a small mini PC, the NiPoGi P1, for €200, to run a few experiments at home. One of them: run two open models, Gemma 4 E4B for general questions and Qwen2.5-Coder 7B for code, on that box with no internet access at all, and use them from my Mac over the home network for a week. This post covers: 1. The hardware, and whether its "AMD Radeon" sticker means a real GPU. 2. How to build the same setup, step by step: Ollama, the models, network access and a firewall that keeps the box off the internet. 3. The real numbers, in tokens per second, on CPU and on the integrated GPU. 4. Three things that made it slow that had nothing to do with the model. 5. What I used it for, whether more RAM would help, and my verdict. --- The hardware: a 15 W laptop chip in a box The NiPoGi P1 is a mini PC that fits in one hand. Mine has this configuration: | Part | What it is | | --- | --- | | CPU | AMD Ryzen 3 3300U: 4 cores, 4 threads, Zen+, 15 W (specs) | | GPU | Radeon Vega 6, integrated in the processor | | RAM | 16 GB DDR4 | | Storage | 512 GB SSD | | Price | €200, what I paid | Does it have a GPU? Yes, but not the kind people mean when they talk about running AI. The Vega 6 lives inside the processor and has no memory of its own: it borrows from the same 16 GB of system RAM. When I checked from inside the container, Vulkan reported it as AMD Radeon Graphics (RADV RAVEN), so it is usable. Keep the "shares the RAM" part in mind, because it explains most of the numbers later. The 3300U is a 2019 laptop processor. I didn't buy this box to win benchmarks. I bought it to find out where the floor is: how much useful AI you get from cheap, quiet, low-power hardware. --- Build the same setup, step by step Any Linux machine on your home network works: an old laptop, a mini PC, a virtual machine. Mine runs Proxmox VE, so everything below runs inside a Debian 13 container with 4 cores and 10 GB of RAM, and the integrated GPU passed into it. Setting up Proxmox itself deserves its own article, so here I'll stick to what works on any Debian or Ubuntu box. Run the commands as root or with sudo. Step 1: Install Ollama (the box still needs internet here) Ollama downloads, runs and serves the models. The official installer sets it up as a systemd service with its own ollama user: curl -fsSL https://ollama.com/install.sh | sh ollama --version If piping a script into a shell makes you uneasy, read it first, or follow the manual install in the Ollama Linux docs. On my AMD box the installer warned that it couldn't detect an NVIDIA or AMD GPU. That warning is about CUDA and ROCm drivers, which this integrated GPU doesn't use anyway. For the integrated GPU, install the Vulkan drivers and check that the GPU shows up: apt install -y mesa-vulkan-drivers vulkan-tools vulkaninfo --summary | grep deviceName Mine reported AMD Radeon Graphics (RADV RAVEN). This step is optional: everything works on the CPU alone. Step 2: Download the models Two downloads, done while the box still had internet: ollama pull gemma4:e4b # 6.6 GB on disk ollama pull qwen2.5-coder:7b # 4.7 GB on disk Gemma 4 E4B is Google's small multimodal model: "E4B" means about 4.5 billion effective parameters, around 8 billion counting embeddings (Ollama library). It reads images too, which matters later. Qwen2.5-Coder 7B is a code model from Alibaba's Qwen team. Step 3: Open Ollama to the home network By default Ollama only listens on localhost. A systemd override changes that, plus a few settings that matter on small hardware: # /etc/systemd/system/ollama.service.d/override.conf [Service] Environment=OLLAMA_HOST=0.0.0.0:11434 Environment=OLLAMA_MAX_LOADED_MODELS=1 Environment=OLLAMA_NUM_PARALLEL=1 Environment=OLLAMA_KEEP_ALIVE=15m Environment=OLLAMA_IGPU_ENABLE=1 systemctl daemon-reload systemctl restart ollama Each line has a reason: - OLLAMA_HOST=0.0.0.0:11434 makes Ollama listen on the network, so the Mac can reach it. - OLLAMA_MAX_LOADED_MODELS=1: both models together don't fit in 10 GB, so only one stays in memory. - OLLAMA_NUM_PARALLEL=1: four slow cores serve one request at a time; parallel requests just queue. - OLLAMA_KEEP_ALIVE=15m unloads a model after 15 idle minutes. - OLLAMA_IGPU_ENABLE=1 lets Ollama use the integrated GPU through Vulkan. Without it, my Ollama version ignored the iGPU. Leave it out if you skipped the Vulkan step. The Vulkan backend itself has its own switch, OLLAMA_VULKAN; on my version (0.35.0) the server log already showed it on (OLLAMA_VULKAN:true), but on older versions you may need OLLAMA_VULKAN=1 as well. Step 4: Test it from another machine From the Mac (or any computer on the same network), ask the API which models it has. Replace the IP with your box's: curl http://192.168.1.214:11434/api/tags If the JSON lists gemma4:e4b and qwen2.5-coder:7b, the network part works. The section "How I used it from the Mac" below turns this into a chat. Step 5 (optional): A chat interface in the browser Open WebUI gives you a ChatGPT-style page with history and image upload. I ran it in Docker on the same box: docker run -d --name open-webui --restart unless-stopped --network host \ -e OLLAMA_BASE_URL=http://127.0.0.1:11434 -e PORT=3000 \ -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main It opens on port 3000. :main follows the latest build; pin a release tag if you want the same version next month. Read the "Three things that made it slow" section before using it on slow hardware: two of its defaults cost me almost a minute per message. --- What "offline" means in this setup "Offline" here doesn't mean the cable is unplugged. The mini PC is on my home network, but it can't reach the internet. The models live on that box, and my Mac talks to them over the local network: Internet ✕ blocked by the firewall (nothing goes out) │ Home router ── 192.168.1.0/24 (home network) │ │ Mac ─── HTTP :11434 ──▶ Mini PC (terminal, HTTP :3000 ──▶ Ollama + Gemma + Qwen browser) Open WebUI The Mac still has internet. What matters is where my prompts go: from the Mac, across the home network, to the mini PC, and nowhere else. The mini PC has no route out, so even a misbehaving tool inside it has nothing to send data to. Step 6: Close the door The internet was needed only for steps 1, 2 and 5. After that, a firewall that drops all outgoing traffic turns the box into an offline AI server. I did it with the Proxmox firewall on the container. On a plain Debian or Ubuntu box, ufw does the same: ufw default deny incoming ufw default deny outgoing ufw allow from 192.168.1.0/24 to any port 22 proto tcp # SSH ufw allow from 192.168.1.0/24 to any port 11434 proto tcp # Ollama API ufw allow from 192.168.1.0/24 to any port 3000 proto tcp # Open WebUI ufw allow out 67/udp # DHCP renewals ufw enable What matters in it: - Outgoing traffic is denied by default, so the box can't open a connection to anything. Replies to the requests it accepts still go back, because the firewall tracks connections. - Inbound, only three ports, and only from the home network. Keep the SSH rule if the box has no screen, or you lock yourself out. - The DHCP rule lets the box ask to renew its IP lease; ufw's built-in rules already accept the router's reply. A DHCP reservation in your router keeps the address stable for the Mac. If you give the box a static IP instead, drop the rule. Networks with IPv6 or other extras may need more rules, so run the check below. - Docker writes its own firewall rules for ports published with -p, and traffic to those ports skips ufw's input rules. With --network host, as above, nothing is published: Open WebUI listens on the host itself, so the port 3000 rule applies. If you run other containers with -p, check them separately. To check it, run something that needs the internet on the box and watch it fail: curl -sS --max-time 5 https://ollama.com || echo "no internet, as expected" Updates and new models now mean opening the door on purpose (ufw disable, update, ufw enable). That's the point. One honest limit: Ollama's API has no authentication. Anyone on my home network, including guests on the Wi-Fi, could use the models. The firewall keeps the internet out; it doesn't pick who inside the house gets in. --- The numbers: tokens per second I measured both models with the same coding prompt, generating 150 tokens, first on CPU only and then with Vulkan on the integrated GPU. This is one week of real use with a few measurements, not a controlled lab benchmark, so here is exactly how I measured: | | | | --- | --- | | Ollama | 0.35.0, ollama run <model> --verbose | | Models | gemma4:e4b and qwen2.5-coder:7b, default 4-bit tags | | Context | Ollama's default (OLLAMA_CONTEXT_LENGTH not set) | | Container | 4 cores, 10 GB RAM, iGPU passed in | | When | The setup day, 2 October; not re-measured at the end of the week | Two numbers matter: - Generation: how fast the answer appears. This is the speed you feel. - Prompt reading: how fast the model reads what you send. It matters when you paste a long file or log. | Model | Generation, CPU | Generation, Vulkan | Prompt reading, CPU | Prompt reading, Vulkan | | --- | --- | --- | --- | --- | | Gemma 4 E4B | 5.5 tok/s | 8.1 tok/s | 14.4 tok/s | 16.8 tok/s | | Qwen2.5-Coder 7B | 5.5 tok/s | 4.5 tok/s | 10.0 tok/s | 27.7 tok/s | The integrated GPU didn't make everything faster. It changed which part was fast. For Qwen, prompt reading got almost three times faster while generation got slower. For Gemma, generation went up by about half. I don't have a clean explanation for why the two models moved in opposite directions, so I kept Vulkan on, because it won for the model I used the most. The pattern makes sense once you remember the shared RAM. Reading a prompt is heavy math, and the GPU's extra compute helps. Generating each new token means reading the model's weights from memory again, and the iGPU reads from the same RAM, at the same speed, as the CPU. To put 8 tokens per second in human terms: a long paragraph takes 20 to 30 seconds to finish appearing. You can read along, but you wait. Switching models costs more. Only one fits in memory, so the first message after a switch spends 10 to 20 seconds loading the other one. --- Three things that made it slow (none of them was the model) Back to the 24-second "Olá". It came from two defaults I didn't know about. A third cost showed up later in the week. 1. Thinking mode was on by default Gemma 4 supports a "thinking" mode, and in Ollama it's on by default. For a simple "Olá", the model wrote about 700 characters of internal reasoning before answering. | Mode | Time to answer "Olá" | | --- | --- | | Thinking on (default) | ~25 s | | Thinking off | ~2 s | The model wasn't slow; it was doing far more work than the question needed (192 generated tokens instead of 10). I turned thinking off by default (Open WebUI has a "Think" switch in the model's advanced parameters) and switch it on only for a hard question. 2. The chat interface added 2,000 tokens to every message Even with thinking off, Open WebUI was still slow. The Ollama logs showed why: my "Olá" arrived at the model as 2,051 tokens of input, when the message itself is a handful. Open WebUI attaches the descriptions of its built-in tools (memory, code interpreter, web search, image generation) to every message for models that support tool calling, and Gemma 4 does. On a cloud model you never notice. Here, the model spent about 55 seconds reading those tools and 1.5 seconds writing the answer. The tools were also useless: web search with no internet doesn't search anything. The fix was to untick those capabilities in the model's settings (Admin Panel, Settings, Models) and to turn off the extra tasks that call the model behind your back: tag generation, follow-up suggestions and autocomplete. Every one of those is another request in a queue of one. On slow hardware, the size of the prompt matters more than the size of the answer. Do the math for any tool you put in front of a local model: at 15 to 30 tokens per second of prompt reading, 10,000 tokens of system prompt means 5 to 11 minutes before the first word. That rules out most coding agents built for cloud models on this box. 3. The model switch Not a bug, a cost: 10 to 20 seconds whenever I jumped between Gemma and Qwen. I learned to stay in one model per session. --- How I used it from the Mac Two ways, both over the home network. The terminal. I installed only the Ollama client on the Mac and pointed it to the mini PC. I use the fish shell, so the setup is two lines plus one function per model: set -Ux OLLAMA_HOST http://192.168.1.214:11434 function gemma ollama run gemma4:e4b --verbose --think=false $argv end Typing gemma opens an interactive chat that runs on the mini PC. --verbose prints the speed after every answer, which turned the whole week into a small benchmark: eval rate: 9.73 tokens/s prompt eval rate: 7.54 tokens/s total duration: 1.81s That run was a short greeting; a real three-sentence explanation of DNS took about 16 seconds end to end, at around 6 tokens per second. The browser. Open WebUI on http://192.168.1.214:3000, for the two things the terminal does badly: keeping a searchable history and sending images. During the week I used it for three things: | Use | Model | How it went | | --- | --- | --- | | Quick questions ("what does this flag do?") | Gemma, terminal | The best fit. Short answers arrive in seconds. | | Small code: explain a snippet, write a function, read a pasted log | Qwen | Useful for small pieces. Pasting code is where Vulkan's faster prompt reading pays off. | | Reading screenshots and photos | Gemma, Open WebUI | It works, and nothing leaves the house. Slower than text. | What I didn't do is real daily work: long conversations, large files, an agent editing a project. At 5 to 8 tokens per second, the waiting adds up fast. --- Would 32 GB of RAM make it faster? This was my first instinct, and it's mostly wrong. More RAM lets you load bigger models. It doesn't make generation faster. Generating each token means reading the model's weights from memory, so the ceiling is roughly memory bandwidth divided by model size. This is a rule of thumb, not an exact formula, but it's consistent with what I measured: Dual-channel DDR4-2400: 2 channels × 8 bytes × 2,400 MT/s ≈ 38 GB/s (theoretical peak) Qwen2.5-Coder 7B: 4.7 GB of weights Ceiling ≈ 38 / 4.7 ≈ 8 tokens/s (measured: 4.5 to 5.5) The 38 GB/s is the theoretical peak. Real memory traffic gets less than that, which is part of why the measured speed sits below the ceiling. The 3300U's memory controller tops out at DDR4-2400 in dual channel (Notebookcheck). Going from 16 to 32 GB doesn't move that number. It lets you load a 14B model, which is about twice as big, so it would generate roughly half as fast. One exception is worth checking. Reviews of this model show units shipping with a single 16 GB stick and one free slot. One stick means single channel, half the bandwidth. If that's your unit, two matched sticks are the one memory upgrade that can make it faster. Check before you buy: sudo dmidecode -t memory | grep -E "Size|Locator|Speed" What would really change the experience is a different class of machine: one where the GPU has fast memory and lots of it. A mini PC like the Bosgame M5, with an AMD Ryzen AI Max+ 395 and 128 GB of LPDDR5X shared between CPU and GPU, has around 256 GB/s of bandwidth. By the same rule of thumb, that's a ceiling several times higher for the same model, and enough memory for much larger ones. I haven't tested one myself. A friend bought one, tested it and is happy with the results, but it's a big investment: at the time of writing it costs several times more than my mini PC, and prices move a lot with memory supply. --- So, was it worth it? My verdict after a week: worth it for quick questions, privacy and small pieces of text or code. Too slow for daily work. | | Offline on the mini PC | Cloud model | | --- | --- | --- | | Privacy | Prompts never leave the house | Prompts go to a provider | | Cost per use | No API fees (hardware and electricity only) | Subscription or per token | | Works without internet | Yes, anything on the home network | No | | Speed | 5 to 8 tokens/s; long prompts are painful | Fast enough not to think about it | | Quality on hard problems | A 4B to 7B model: fine for small tasks | Much stronger | | Agents and big contexts | Not realistic here | Yes | The part I'd keep even if I switched the box off tomorrow is what it taught me: on modest hardware, speed is mostly about memory bandwidth and prompt size, and the defaults of tools built for cloud models (thinking on, a dozen built-in tools) can make a working setup feel broken. If you have an old laptop or a cheap mini PC, try this before buying anything. A weekend is enough to learn where your floor is, and the firewall rules above keep the experiment truly offline. --- FAQ Do I need Proxmox? No. Proxmox only gives the models their own container on a box that runs other things too. The steps above work on any Debian or Ubuntu machine; I'll cover the Proxmox side in a separate article. Why Gemma 4 E4B and Qwen2.5-Coder 7B? They are small enough to fit in 10 GB of RAM at 4-bit quantization, and they cover two different needs: general questions with image input, and code. Is Ollama's network API safe? It has no authentication. Only expose it to a network you trust, and restrict it with firewall rules to the clients that need it. Should I use the integrated GPU? Measure both. On this box, Vulkan made prompt reading much faster for Qwen and generation faster for Gemma, but generation slower for Qwen. Ten minutes of testing with --verbose answers it for your hardware. --- Takeaway - "Offline" can be a firewall rule. Block outbound traffic from the AI box and use it from your other devices over the home network. - An integrated GPU shares your RAM. It speeds up prompt reading more than generation. - Check the defaults first. Thinking mode and built-in tools turned a 2-second answer into 25 to 55 seconds. - Prompt size is the hidden cost. Every token a tool adds has to be read at 15 to 30 tokens per second. - More RAM buys capacity, not speed. Bandwidth sets the ceiling; dual channel matters more than 32 GB. - Local AI is a great second tool, not yet a replacement on cheap hardware. What's the smallest machine you've run a local model on, and what did you actually use it for? Tell me in the comments. --- I'm Diogo Soares, a Staff AI Engineer working on AI agents and legacy modernization. If this was useful, follow me here on DEV.to and on Instagram at @diogosoares.dev, where the numbers from this experiment become a carousel you can save for your own homelab. This article also gets a video walkthrough on my YouTube channel, Diogo Soares Dev, so subscribe there for the next ones. Let's also connect on LinkedIn, or check out diogosoares.dev.

AI セルフホスト 5 製品を公式 compose で立てた直後、最初に来た人が管理者になれたのは n8n と Open WebUI だった n8n・Open WebUI・LiteLLM・Langflow・Flowise を、公式の compose ファイルと .env の例のまま起動して確かめました。 | 製品（版） | 立てた直後 | 例のパスワード | |---|---|---| | n8n 2.44.5 | ログインなしで owner を作れる。2 人目は拒否 | Postgres が changePassword で入れる | | Open WebUI 0.12.3 | 最初にサインアップした人が admin。2 人目は 403 | なし | | LiteLLM 1.106.2 | マスターキーが空だと起動を拒否する | Postgres が dbpassword9090 で入れる | | Langflow 1.12.7 | 自動ログインは既定で無効（403） | Postgres が langflow で入れる | | Flowise 3.1.4 | 公式の手順では起動しなかった（後述） | なし（SQLite） | - n8n と Open WebUI は、管理者を作るまでの間なら、外から先に来た人が管理者になれます。「まだ誰もいない」ことも、ログインなしの API で分かります。 - LiteLLM と Langflow は、最近の版で安全な既定に変わっていました。ただし Langflow は、古い版のイメージや LANGFLOW_AUTO_LOGIN=true で、誰でもスーパーユーザーになります。 - データベースの例のパスワードは、3 製品で .env や compose に書かれたまま通りました。 - 5 つとも、公式の compose ファイルはアプリのポートをホストの全インターフェースに公開しています。 これらをセルフホストしていて、外に出す前に何を変えるか決めたい人向けです。 Intruder が 2026 年 3 月 27 日に公開した調査 From enterprise chatbots to gooner caves: exposed AI infrastructure is rampant は、インターネットに公開された AI 関連のサービスに、認証なしで使えるものが多いと報告しています。その中の "an alarming number of hosts appearing to be in a freshly installed setup, without any authentication"（入れたばかりの状態のまま、認証なしで公開されているホストが驚くほど多い）という一文を見て、公式の手順で立てた直後の内側がどうなっているかを確かめることにしました。外から見た数の話は、Intruder の調査を紹介した 【悲報】100万台のAIサービスをスキャンしたら「史上最悪のセキュリティ」だった件 に詳しく書かれています。点検に使った CLI と検証のワークフローは OTA-EITA/ai-selfhost-audit に置いてあります。 対象と前提 - 各プロジェクトの公式の compose ファイルと .env の例を、次の版のまま使いました（2026 年 10 月 29 日時点で、公開から 7 日以上たっている最新の安定版）。 - n8n: n8n-hosting の withPostgres（.env の N8N_VERSION=2.44.5） - Open WebUI: v0.12.3 の docker-compose.yaml - LiteLLM: v1.106.2 の docker-compose.yml と .env.example - Langflow: v1.12.7 の docker_example - Flowise: 3.1.4 の docker/ - 起動したのは 2026 年 10 月 29 日、GitHub Actions の使い捨てのランナーです。外から届かないよう、公開ポートは override ファイルですべて 127.0.0.1 に付け替えています。付け替える前の compose が全インターフェースに公開していることは、docker compose config で確かめました。 - イメージが latest や main の製品は、上の版のタグに固定しました。 立てるときに変えること 先に、確かめた結果から決めた手順を載せます。理由は製品ごとの節にあります。 | 製品 | 外に出す前にやること | |---|---| | 共通 | 管理者を作るまではポートを 127.0.0.1: で公開する。DB のポートは公開しない。例のパスワードを作り直す | | n8n | 先に owner を作る（または N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true で env から作る）。N8N_ENCRYPTION_KEY と N8N_RUNNERS_AUTH_TOKEN を生成する。2.45.5 以降にする | | Open WebUI | WEBUI_ADMIN_EMAIL と WEBUI_ADMIN_PASSWORD を設定する。WEBUI_SECRET_KEY を生成する。CORS_ALLOW_ORIGIN を自分のオリジンにする | | LiteLLM | LITELLM_MASTER_KEY と LITELLM_SALT_KEY を生成する。DATABASE_URL のパスワードを変える | | Langflow | イメージを 1.10.3 以降に固定する。LANGFLOW_AUTO_LOGIN を true にしない | | Flowise | 先に owner を登録する。TRUST_PROXY をプロキシのアドレスにする | n8n: ログインなしで owner を作れる n8n は、最初に owner（管理者）を作るまでの間、owner を作る API を認証なしで受け付けます（owner.controller.ts L25-29、ownership.service.ts L227-232）。条件は「まだ owner がいないこと」だけです。 curl -s http://127.0.0.1:5678/rest/settings | jq .data.userManagement.showSetupOnFirstLoad curl -s -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:5678/rest/owner/setup \ -H 'content-type: application/json' \ -d '{"email":"lab-owner@example.com","firstName":"Lab","lastName":"Owner","password":"Lab-Owner-Passw0rd"}' | 確かめたこと | 結果 | |---|---| | ログインなしで GET /rest/settings | showSetupOnFirstLoad: true | | ログインなしで POST /rest/owner/setup | 200。送ったメールアドレスで owner ができた | | もう一度 POST /rest/owner/setup | 400 Instance owner already setup | | owner を作ったあと、ログインなしで GET /rest/workflows | 401 | /rest/settings は誰でも読めるので、「この n8n にはまだ owner がいない」ことが外から分かります。owner を作ったあとは、ほかの API は 401 になりました。危ないのは、立ててから owner を作るまでの間です。 .env には、POSTGRES_PASSWORD=changePassword や RUNNERS_AUTH_TOKEN=changeRunnerAuthToken のような例の値が入っています。Postgres には実際に changePassword でログインできました。 なお、n8n の基本認証（N8N_BASIC_AUTH_*）は 2023 年 6 月の #6362 で削除されています。今の n8n でこの変数を設定しても、何も変わりません。 Open WebUI: 最初にサインアップした人が admin Open WebUI は、最初に登録したユーザーを admin にして、そのあとのサインアップを止めます（auths.py L811-827）。 curl -s http://127.0.0.1:3000/api/config | jq .onboarding curl -s -X POST http://127.0.0.1:3000/api/v1/auths/signup -H 'content-type: application/json' \ -d '{"name":"first","email":"first@example.com","password":"Lab-First-Passw0rd"}' | jq .role | 確かめたこと | 結果 | |---|---| | ログインなしで GET /api/config | onboarding: true | | 最初の POST /api/v1/auths/signup | 200、role: admin | | 2 人目の POST /api/v1/auths/signup | 403 | n8n と同じで、/api/config から「まだ誰も登録していない」ことが分かります。WEBUI_ADMIN_EMAIL と WEBUI_ADMIN_PASSWORD を設定すると、起動時に admin が作られてサインアップも止まります（env.py L804-806）。 LiteLLM: マスターキーがないと起動しない LiteLLM は、マスターキーが未設定・空・sk-1234 のときは起動を拒否します（master_key_boot_check.py）。公式の .env.example は LITELLM_MASTER_KEY = "" なので、そのまま起動すると次のように止まりました。 LiteLLM proxy refused to start: the master key is empty. マスターキーを設定して起動し直すと、/health と /metrics はキーなしでは 401 でした。安全側に倒した既定です。 一方、compose ファイルには DATABASE_URL: "postgresql://llmproxy:dbpassword9090@db:5432/litellm" が直接書かれていて、Postgres は 5432:5432 で全インターフェースに公開されています。実際に dbpassword9090 でログインできました。Postgres にはキーのハッシュや、暗号化されたプロバイダーの認証情報が入ります。 LITELLM_SALT_KEY を設定しないと、その暗号化にもマスターキーが使われます（encrypt_decrypt_utils.py L32-40）。 Langflow: 既定では安全、ただし 1.10.2 より前のイメージに注意 Langflow のコードの既定は今も AUTO_LOGIN=True です（auth.py L96-104）。公式のイメージは 1.10.2 から LANGFLOW_AUTO_LOGIN=false を入れていて（build_and_push.Dockerfile L234-235）、イメージで動かす限りは無効です。 | 確かめたこと | 結果 | |---|---| | 1.12.7 のイメージのまま GET /api/v1/auto_login | 403 | | LANGFLOW_AUTO_LOGIN=true にして同じリクエスト | 200。スーパーユーザーのアクセストークンが返った | | 例のパスワード langflow で Postgres にログイン | できた | 公式の docker_example はイメージが langflowai/langflow:latest なので、今 pull すれば安全な既定になります。古いタグに固定しているなら注意が必要です。2026 年 10 月 30 日の時点で、CISA の 悪用が確認された脆弱性のカタログ（KEV）には Langflow の脆弱性が 6 件載っています。 | CVE | KEV に載った日 | 対象の版 | |---|---|---| | CVE-2025-3248 | 2025-05-05 | 1.3.0 未満 | | CVE-2026-33017 | 2026-03-25 | 1.8.2 以前 | | CVE-2025-34291 | 2026-05-21 | 1.6.9 以前 | | CVE-2026-55255 | 2026-07-07 | 1.9.1 未満 | | CVE-2026-0770 | 2026-07-21 | 1.7.3 以前 | | CVE-2026-9198 | 2026-08-04 | 1.10.0 以前 | 対象の版は GitHub Advisory Database の記載です。KEV の 6 件を外すだけなら 1.10.1 以降で足りますが、自動ログインが既定で無効になるのは 1.10.2 から、MCP の stdio サーバーの設定からのコマンド実行（GHSA-w794-rj3p-xv45、critical）が直ったのは 1.10.3 からです。固定するなら 1.10.3 以降にします。 Flowise: 公式の手順では起動しなかった Flowise も、最初に登録した人が owner になる作りです（account.service.ts L178-197）。これを確かめるつもりでしたが、起動できませんでした。 1. 公式の compose と .env.example のままでは、ログのディレクトリを作るところで mkdir '' に失敗して落ちます。compose が全変数を LOG_PATH=${LOG_PATH} の形で渡すので、.env.example でコメントアウトされている変数が空文字になるためです（#6030、修正の PR #6031 はまだ開いています）。 2. issue のとおりパスを .env に入れると先へ進みますが、3.1.4 のイメージ自体が依存パッケージのエラーで起動に失敗しました。これも既知の問題です（#6688）。 そのため Flowise は、ソースを読んだ結果だけを点検ツールのルールにしています。なお Flowise の FLOWISE_USERNAME / FLOWISE_PASSWORD による基本認証は、ドキュメントで 3.0.1 から非推奨とされていて（app-level.md）、3.1.4 のソースにはもう参照がありません。設定しても効きません。 設定から見つける ここまでのことは、compose ファイルと .env を読めば分かります。ai-selfhost-audit は、compose ファイルの image から製品を見分けて、製品ごとの設定とイメージの版を調べます。Docker にもネットワークにも触りません。 go install github.com/OTA-EITA/ai-selfhost-audit/cmd/ai-selfhost-audit@latest cd your-compose-dir ai-selfhost-audit n8n の公式の compose ファイルに使うと、次のようになります。 SEVERITY ID SERVICE LOCATION FINDING HIGH N8N010 n8n docker-compose.yml:27 n8n version has an unpatched expression sandbox escape MEDIUM GEN007 n8n .env:8 Database password is an example from an official compose file MEDIUM GEN007 postgres .env:4 Database password is an example from an official compose file MEDIUM GEN007 postgres .env:8 Database password is an example from an official compose file MEDIUM N8N001 n8n docker-compose.yml:27 First visitor can claim the n8n owner account MEDIUM N8N003 n8n .env:10 Task runner auth token is an example value MEDIUM N8N008 n8n docker-compose.yml:27 n8n SSRF protection is off INFO GEN002 n8n docker-compose.yml:42 Application port published on all host interfaces 8 findings: 1 high, 6 medium, 0 low, 1 info HIGH の N8N010 は、.env が指定している 2.44.5 に、まだ修正されていない式のサンドボックス脱出（GHSA-gx3v-3x3v-f8r5）があるという指摘です。2.44 系には修正版がなく、2.45.5 以降に上げる必要があります。 ルールは全部で 50 個です。製品ごとに、上で見た「最初の訪問者」「例の値」のほか、コード実行やファイルアクセスの制限を外す設定、既知の脆弱性がある版などを見ます。各ルールには、根拠になるソースの行や advisory へのリンクを付けました。 確かめていないこと - Flowise の「最初に登録した人が owner」の挙動。上のとおり起動できなかったので、ソースを読んだだけです - 公開されている「入れたばかり」のホストが、実際にこの時間差で残ったものかどうか。立ててから管理者を作るまでの間に外から見えていれば同じ状態になる、というところまでしか言えません - 公式の compose 以外の立て方（Helm チャート、各社のマネージド版、ワンクリックのテンプレート） 参考 - From enterprise chatbots to gooner caves: exposed AI infrastructure is rampant（Intruder） - n8n-io/n8n-hosting withPostgres - open-webui/open-webui v0.12.3 - BerriAI/litellm v1.106.2 - langflow-ai/langflow v1.12.7 - FlowiseAI/Flowise 3.1.4、#6030、#6688 - CISA Known Exploited Vulnerabilities Catalog - GitHub Advisory Database: Langflow - OTA-EITA/ai-selfhost-audit

Run a private ChatGPT-style UI for local models with Open WebUI You can get a ChatGPT-style interface that runs on your own machine and talks to local models. Open WebUI is a self-hosted web front end for Ollama and OpenAI-compatible APIs, and the install is one command. The short version is on the Deduped use-case page. Here is the full path with the exact commands from the README. Option 1: pip If you have Python set up, install and run: pip install open-webui open-webui serve Then open the local address it prints in your browser and create the first account. The first account becomes the admin. Option 2: Docker, with Ollama on the same machine This is the common setup. Ollama runs on the host and the container reaches it through host.docker.internal: docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main Open localhost. What each flag does: - -p 3000:8080 publishes the UI on port 3000. - --add-host=host.docker.internal:host-gateway lets the container see Ollama on the host. - -v open-webui:/app/backend/data keeps chats and settings in a named volume, so upgrades do not wipe them. - --restart always brings it back after a reboot. Option 3: Ollama on another server Set OLLAMA_BASE_URL to the remote address: docker run -d -p 3000:8080 -e OLLAMA_BASE_URL=https://example.com -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main Replace the example URL with your own server. Option 4: NVIDIA GPU image If you want the CUDA build: docker run -d -p 3000:8080 --gpus all --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:cuda This needs the NVIDIA container toolkit on the host. Pull a model Open WebUI is only the interface. Make sure Ollama has something to serve: ollama pull llama3 Then pick it from the model dropdown at the top of a new chat. Any model Ollama lists will appear. Why bother - Your prompts stay on your hardware when you use local models. - One UI for local models and OpenAI-compatible endpoints. - Chat history lives in your own volume. The Deduped site also has pages on chatting with your documents using local RAG and the full Open WebUI repo page. Tips - Back up the open-webui volume before upgrading the image. - Do not expose port 3000 to the internet without a reverse proxy and strong passwords. - If the container cannot see Ollama, check the --add-host flag first, then that Ollama is listening. Who this is for People who want a polished chat UI for local models without sending data to a hosted service. If you only chat occasionally with a hosted model, a plain subscription is simpler. Repo: open-webui/open-webui. --- Get one email every Monday with the week's hottest AI repos and exactly how to use them: subscribe free at dedupedai.com

1) ChatGPT → Open WebUI The same chat window you're used to, but it runs models on your own machine. Works offline once it's set up. 157K stars on GitHub. open-webui/open-webui

Open WebUI 0.12.4: HIDE ANY CONTROL from your users, skills that load ON DEMAND, compaction you can see, multi-select chats, bulk file downloads, a big ACCESSIBILITY pass and group saves in under a second with thousands online. 0.12.3 shipped nine days ago. 0.12.4 brings 119 changelog entries from 385 commits: 42 new features, 68 fixes and 9 changes. It also contains security fixes, so update soon. You decide what your users see. Admins can now hide single controls from users, under Visible controls in Admin Settings > Interface or with UI_VISIBILITY. That covers the + menu (Capture, Compare text, Attach Webpage, Attach Files, Attach Notes, Attach Knowledge and Reference Chats), the /status, /model and /settings commands, Fork, Merge Responses, Preview, Artifacts, Archive and Tags in chats, the usage info, the capabilities, default features and built-in tools in the model editor, Set as default and Keep in Sidebar for models, and settings such as the Usage tab and the speech engines. Hidden controls keep their values and the features behind them keep working. Admins still see everything. Open WebUI also hides options that cannot take effect: Capture without a Vision model, Attach Notes without the Notes permission, the search engine settings while web search is off, the Call button without speech-to-text, and many more like them. Saved values stay for when they apply again. The Access button only shows for people allowed to share, and the + menu and the # and @ lists only offer what can actually be attached. Smaller prompts, and compaction you can see. Turn on Load selected skills on demand in Admin Settings > General, or set ENABLE_SKILL_LAZY_LOADING, and skills selected in the chat or attached to a model are only listed. The model loads one when it needs it, so their full instructions no longer ride along with every message. Skills you mention in the message still load right away. It is off by default and needs the built-in Skills tool. A "Context compacted" line now marks the spot where older messages were summarized. Open it to read the summary. It also shows inside a reply when compaction ran between tool calls, and progress and errors now show in the chat, where they used to be pop-ups. Compaction also runs in temporary chats and in short chats that are already over the threshold, such as one question with a reply full of tool output, so the follow-up no longer fails with a context length error. Tools from tool servers, Open Terminal included, now reach the model in the same form after a restart, so your provider's prompt cache keeps working and long chats are not processed again from scratch. Built for big instances. With thousands of users online, saving a group or changing its members or permissions now finishes in well under a second. It took several seconds and reloaded the open chat of everyone online. Renaming, sharing, moving or deleting a folder, and deleting all chats, got the same fix. Posting in a channel with many members online returns in a fraction of a second. The Admin Analytics dashboard uses fewer and lighter database queries and opens faster on instances with many messages. Analytics now ranks models and users by tokens by default, with a switch back to messages. The usage chart adds volume and activity views, a single model view, a comparison with the previous period, a choice of time steps and the Year to date and Last 12 months ranges. For admins with bigger setups: - LDAP users without a mail attribute can sign in through a default email domain (LDAP_DEFAULT_EMAIL_DOMAIN). Pick a domain you control: those users get username@domain and sign in to any existing account with that address. - The Hidden Models permission lets a group build workspace models on hidden base models, which stay out of their model picker. - With audit logging on and /chat removed from AUDIT_EXCLUDED_PATHS, every reply and tool call round writes an audit entry with the model and the input, output and total tokens. - Connections set to OAuth now also send the user's OAuth token when the user calls the API with an API key. - MCP connections work with servers on the stateless 2026-07-28 protocol, and older servers still connect. Accessibility. Screen readers now announce buttons, menus, switches, headings, lists and status changes by name across the app, down to when a reply starts and finishes. Keyboard users move through the input, user, chat and Terminal menus with the arrow keys, and focus stays or returns where you expect in the model picker, the sidebar and Archived Chats. Notifications in the light theme and the dates in Archived Chats meet the 4.5:1 contrast minimum, and the Archived Chats and Keyboard lists work at 400% zoom. With Accessibility Mode on, pinch zoom works on phones and small buttons such as More and Eject in the model picker are at least 24 pixels. Everyday things. - Shift-click a chat in the sidebar to start a selection, then archive or delete the selected chats together. Escape clears it. - Manage Files in Settings > Data Controls downloads single files, or selects several, or every file matching a search, to delete them or download them as one zip. - On phones, swipe left across a chat to pull in Chat Controls. - The terminal file browser has a grid view, item counts on folders and hover previews on larger screens. - Folders get a New Chat item in their menu and a description. - The sidebar hover preview of a chat shows how many turns it has. - Click a setting's label to flip its switch or focus its field. - If the page reloads or drops its connection while Ask User, a tool approval or an MCP input request waits for you, the question comes back when you reopen the chat within a minute. - Chat Controls save one setting at a time, so a copy of the chat open on another device no longer wipes your system prompt with older settings. - Files dropped into a knowledge base show up right away, switch to Processing on the server and only show as done once they are indexed. - Hovering an owner's name across the workspace opens their profile card. - The model can edit a note by finding and replacing text. The bugs you told us about. Since 0.12.3, chats opened through a share link, or by an admin viewing another user's chat, reloaded over and over and jumped back to the bottom, so you could not scroll up. Fixed. Since 0.12.3, messages showed an extra space at the start of each paragraph and before bold, italic or linked text. Fixed. Archiving all chats and then deleting a folder deleted those archived chats for good. Fixed: Archive All Chats now takes the chats out of their folders. More Concise and Add Details now rewrite the reply. The model used to get only the instruction and answer things like "OK, I'll keep answers shorter". Fixed. Deleting the chat you were looking at left its messages on screen, and the next message failed. Fixed. On SQLite, closing a page while it was still loading could lose database connections until requests hung or failed with a 503. Fixed. Since 0.12.3, with the Redis websocket manager and retry_on_timeout set, new connections could hang after a Redis drop until the instance was restarted. Fixed. Attached web pages came back empty on fresh installs after a broken update of a library underneath. Fixed. Images the model made after a tool approval never showed up, and the model kept making more. Fixed. A stop sequence containing % stopped every message from sending. Fixed. Security. This release contains security fixes. They are not listed in the changelog; the advisories follow once their CVEs are assigned. Update as soon as you can. Before you upgrade: - Direct Integrations is off by default. While it is off, tool servers and Open Terminal connections that users and admins saved in their Integrations settings are no longer used in chats. If you rely on them, turn on Direct Integrations in Admin Settings > Connections or set ENABLE_DIRECT_INTEGRATIONS. - The Docker image now runs Python 3.12 on Debian 13. Custom functions, tools and packages installed with pip inside the container need versions that support Python 3.12. - MCP_INITIALIZE_TIMEOUT (10 seconds by default) now also limits listing tools and reading resources, so slow MCP servers may need a higher value. MCP connections only follow redirects that stay on the same address. - Saving a model, prompt, tool, skill, knowledge base, note, channel or calendar no longer changes who it is shared with. Sharing changes only in the item's Access settings. Sharing permissions now also apply through the API, and a change you are not allowed to make is refused with an error. - Manage Files lists only your own files, for admins too. - Holding Shift over a sidebar chat no longer shows the quick Archive and Delete buttons, since Shift-click now selects. Full changelog: github.com/open-webui/open-webui/releases/tag/v0.…