[{"data":1,"prerenderedAt":226},["ShallowReactive",2],{"seo-verification":3,"blog-open-webui-ollama-on-vps-multi-user-interface-for-local-llms-ma-en":6,"promo-bar-likely":225},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-open-webui-ollama-on-vps-multi-user-interface-for-local-llms-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":164,"ctaBody":165,"ctaButton":166,"ctaUrl":167,"relatedPosts":168},316,"open-webui-ollama-on-vps-multi-user-interface-for-local-llms",{"fr":12,"en":10,"ar":13,"es":14},"open-webui-ollama-vps","واجهة-ويب-open-webui-مع-ollama-على-vps-للفرق","open-webui-ollama-en-vps-interfaz-web-multiusuario-para-llm","Open-WebUI + Ollama on VPS: multi-user interface for local LLMs","Give your entire team a multi-user web interface for your Ollama models: RAG, model management, SSO via OpenID Connect — no cloud dependency.",18,7,false,"2026-08-30T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},1,"Artificial Intelligence","intelligence-artificielle","bg-purple-500\u002F10 text-purple-400","ia",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fopen-webui-ollama-vps-poster.svg","Ollama serves your language models through a local API. Open-WebUI adds the interface layer: a full web application with user management, document RAG, conversation history and SSO authentication. Deploying both on your VPS gives your entire team access to private LLMs without exposing the raw API or requiring command-line access. This guide covers installation, reverse proxy, SSO and access management. It also covers web search through SearXNG, what to do when it stops returning anything, and what you can actually measure about a team instance's usage.",[35,39,49,52,71,74,77,80,83,111,114,117,132,134,137,144,147,149,152,154,161],{"type":36,"title":37,"body":38},"h2","Why add Open-WebUI to your Ollama server","Ollama exposes a REST API compatible with OpenAI — efficient for developers, inaccessible for other team members. Open-WebUI bridges that gap: a complete web interface that connects to Ollama (or any OpenAI-compatible provider) and turns an inference server into a collaborative tool.\n\nThe repository has passed 155,000 GitHub stars. Mind the licence: it is not MIT. The project ships its own licence, a three-clause BSD with one extra condition: beyond 50 users over a rolling 30 days, you may not alter or remove the \"Open WebUI\" branding unless you have written permission or an enterprise licence. For a small team nothing changes; beyond that, read the LICENSE file before customising the interface. Ollama, for its part, announced a 65 million dollar Series B in July 2026, a sign that the inference engine is settling into development teams for the long term.\n\nThe project is continuously maintained and publishes stable tags at a steady pace: version 0.13.0 dates from 3 November 2026. The pace has a downside, since default behaviours change from one minor version to the next (native tool calling became the default in 0.10.0). Hence the value of pinning a tag and reading the release notes before every update. Open-WebUI covers needs well beyond chat: RAG on local files, management of multiple models, user groups, web search and SSO integration via OpenID Connect.",{"type":40,"title":41,"items":42},"ul","What Open-WebUI concretely adds to your Ollama stack",[43,44,45,46,47,48],"**Multi-user interface**: each team member has their own account, history and conversations — without access to the raw API or command line.","**Native RAG**: import PDF, Markdown or Word files directly from the interface; Open-WebUI indexes them and injects them into each conversation's context.","**Model management**: download, delete and activate Ollama models from the web interface, without going through `docker exec`.","**OpenID Connect SSO**: connect Open-WebUI to your identity provider (Keycloak, Authentik, Google Workspace…) for unified access and centralised revocation.","**Groups and roles**: define who can access which models, who can upload files, who has administration rights.","**No cloud dependency**: all tokens, conversations and files stay on your infrastructure.",{"type":36,"title":50,"body":51},"Hardware and software requirements","Open-WebUI runs in a Docker container and connects to Ollama via the internal Docker network. Both can coexist on the same VPS.\n\nFor a team of 5 to 10 people with quantised 7B models (Q4), plan for at minimum:\n\n- **8 GB RAM** (6 GB for the model + headroom for Open-WebUI and the system)\n- **4 vCPU**: CPU inference is slow with fewer cores; move to 8 vCPU for comfortable daily use\n- **30 GB SSD storage** minimum, plus space for your models (a 7B Q4 model ≈ 4.5 GB, a 13B model ≈ 8 GB)\n- **Docker and Docker Compose** installed\n- A **domain name** pointing to your VPS (required for TLS and SSO)\n- A **reverse proxy** with HTTPS — Nginx, Traefik or Caddy (served over HTTP on a non-local domain or IP, Open-WebUI loses features in the browser: see troubleshooting)\n\nIf Ollama is already deployed on your VPS (see the article \u003Ca href=\"\u002Fblog\u002Fheberger-ollama-vps\">How to host Ollama on a VPS\u003C\u002Fa>), you can skip directly to the Open-WebUI installation.",{"type":53,"title":54,"steps":55},"steps","Deploy Open-WebUI and Ollama with Docker Compose",[56,59,62,65,68],{"title":57,"body":58},"Create the Docker Compose file","Create a working directory then write the compose file:\n\n```bash\nmkdir -p \u002Fopt\u002Fopenwebui && cd \u002Fopt\u002Fopenwebui\n```\n\nContent of `compose.yml`:\n\n```bash\nservices:\n  ollama:\n    image: ollama\u002Follama:latest\n    container_name: ollama\n    volumes:\n      - ollama_data:\u002Froot\u002F.ollama\n    restart: unless-stopped\n\n  open-webui:\n    image: ghcr.io\u002Fopen-webui\u002Fopen-webui:main\n    container_name: open-webui\n    depends_on:\n      - ollama\n    ports:\n      - \"127.0.0.1:3000:8080\"\n    environment:\n      - OLLAMA_BASE_URL=http:\u002F\u002Follama:11434\n      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}\n    volumes:\n      - open_webui_data:\u002Fapp\u002Fbackend\u002Fdata\n    restart: unless-stopped\n\nvolumes:\n  ollama_data:\n  open_webui_data:\n```\n\nThe `WEBUI_SECRET_KEY` must be a long random string, never written in the compose file: generate it with `echo \"WEBUI_SECRET_KEY=$(openssl rand -hex 32)\" > .env && chmod 600 .env`. Docker Compose reads this `.env` file from the directory and substitutes `${WEBUI_SECRET_KEY}`.",{"title":60,"body":61},"Start the stack","Start both services:\n\n```bash\ndocker compose up -d\n```\n\nCheck that both containers are active:\n\n```bash\ndocker compose ps\n```\n\nOllama may take a few seconds to start. Open-WebUI waits for Ollama to be ready thanks to `depends_on`, but if you see connection errors on first start, wait 15 seconds and reload.",{"title":63,"body":64},"Download a first model","From the host, download a model via Ollama:\n\n```bash\ndocker exec -it ollama ollama pull llama3.1:8b\n```\n\nYou can also do it from the Open-WebUI interface once logged in, under **Administration Panel → Models → Download from Ollama.com**.",{"title":66,"body":67},"Configure the Nginx reverse proxy with HTTPS","Open-WebUI listens on `127.0.0.1:3000`. Create an Nginx virtual host to expose it over HTTPS:\n\n```bash\nserver {\n    listen 443 ssl;\n    server_name openwebui.yourdomain.com;\n\n    ssl_certificate \u002Fetc\u002Fletsencrypt\u002Flive\u002Fopenwebui.yourdomain.com\u002Ffullchain.pem;\n    ssl_certificate_key \u002Fetc\u002Fletsencrypt\u002Flive\u002Fopenwebui.yourdomain.com\u002Fprivkey.pem;\n\n    location \u002F {\n        proxy_pass http:\u002F\u002F127.0.0.1:3000;\n        proxy_set_header Host $host;\n        proxy_set_header X-Real-IP $remote_addr;\n        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n        proxy_set_header X-Forwarded-Proto $scheme;\n\n        # WebSocket (required for response streaming)\n        proxy_http_version 1.1;\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection \"upgrade\";\n        proxy_read_timeout 300s;\n    }\n}\n```\n\nObtain the certificate with Certbot:\n\n```bash\ncertbot --nginx -d openwebui.yourdomain.com\n```",{"title":69,"body":70},"Create the administrator account","Open `https:\u002F\u002Fopenwebui.yourdomain.com` in your browser. The **first account created automatically becomes administrator**: create it as soon as the site is online, before anyone else does. Enter an email and password.\n\nFrom the administration panel (**avatar icon → Administration Panel**), you can:\n- define whether new registrants are immediately active or pending validation;\n- create user groups and associate models with them;\n- configure SSO.",{"type":36,"title":72,"body":73},"Configure OpenID Connect SSO","Open-WebUI natively supports authentication via OpenID Connect (OIDC). You can integrate it with Keycloak, Authentik, Authelia, or any compatible provider (including Google Workspace or Microsoft Entra).\n\nIn `compose.yml`, add the following environment variables to the `open-webui` service:\n\n```bash\nenvironment:\n  - OAUTH_CLIENT_ID=your-client-id\n  - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET}\n  - OPENID_PROVIDER_URL=https:\u002F\u002Fyour-idp.example.com\u002F.well-known\u002Fopenid-configuration\n  - OAUTH_PROVIDER_NAME=My SSO\n  - ENABLE_OAUTH_SIGNUP=true\n```\n\nLike the session key, the client secret goes in the `.env` file (`OAUTH_CLIENT_SECRET=…`), not in `compose.yml`.\n\nThe callback URL to declare in your identity provider is `https:\u002F\u002Fopenwebui.yourdomain.com\u002Foauth\u002Foidc\u002Fcallback`.\n\nRestart the stack after modification:\n\n```bash\ndocker compose up -d\n```",{"type":75,"body":76},"tip","To restrict SSO access to a specific email domain (e.g. `@your-company.com`), configure the restriction directly in your identity provider, not in Open-WebUI. Keycloak and Authentik both allow domain filtering at the OIDC client level — this is the safest control point, as it also covers the API.",{"type":36,"title":78,"body":79},"Enable RAG on your documents","Open-WebUI includes a RAG (Retrieval-Augmented Generation) pipeline that allows you to query your local documents in a conversation. Processing happens entirely on your VPS — no document is sent to an external service.\n\nTo enable RAG:\n\n1. From the interface, click the **paperclip** in the input area of a conversation, or use the **Documents** tab in the side menu.\n2. Import a PDF, Markdown, DOCX or TXT file. Open-WebUI chunks it, vectorises it and stores it in its local database.\n3. In the conversation, prefix your message with `#` followed by the document name to inject it as context.\n\nFor advanced use (multiple documents, thematic collections), the **Workspace → Documents** section allows you to organise files into collections and associate them with specific models.\n\nBy default, Open-WebUI uses its own lightweight embeddings engine. For better performance on a large corpus, you can configure a dedicated Ollama embeddings model (for example `nomic-embed-text`) in **Administration Panel → Documents → Embeddings model**.",{"type":36,"title":81,"body":82},"Add web search with SearXNG","Web search is not built into Open-WebUI: the interface queries an external engine, then injects the pages it finds into the model's context. SearXNG, a self-hosted metasearch engine, spares you a paid API key: it queries several public engines for you and returns a single list. That is also its weakness, covered in the troubleshooting section below.\n\nThree settings are enough. On the SearXNG side, open `settings.yml` and add `json` to the `formats` list under `search`, next to `html`: without it, Open-WebUI gets a 403 error. On the Open-WebUI side, open **Administration Panel → Settings → Web Search**, choose `searxng` and enter the query URL, for example `http:\u002F\u002Fsearxng:8080\u002Fsearch?q=\u003Cquery>` (variable `SEARXNG_QUERY_URL`). You can also set `ENABLE_WEB_SEARCH=true` and `WEB_SEARCH_ENGINE=searxng` in `compose.yml`. If both services share a Docker network, the service name works as the host and SearXNG's port does not need to be published to the Internet.\n\nOne trap remains: three switches must be on at the same time, global web search, the model's \"web search\" capability and the button in the current conversation. Miss one and you get an answer without any search, often with no visible error.",{"type":84,"title":85,"headers":86,"rows":90},"comparison","Open-WebUI, AnythingLLM, LibreChat: which interface to choose",[87,88,89],"Criterion","Open-WebUI","AnythingLLM \u002F LibreChat",[91,95,99,103,107],[92,93,94],"LLM backend","Native Ollama + any OpenAI endpoint","OpenAI, Ollama, Azure, LM Studio",[96,97,98],"User management","Built-in, groups, native OIDC","Built-in (AnythingLLM: isolated workspaces)",[100,101,102],"RAG","Native, no configuration required","Native, configurable (LanceDB, pgvector)",[104,105,106],"GitHub stars","155,000+ (own licence, protected branding)","65,000+ (MIT) \u002F 45,000+ (MIT)",[108,109,110],"Primary use case","Team with Ollama already deployed","Advanced multi-source RAG \u002F multi-backend chat",{"type":36,"title":112,"body":113},"Troubleshooting: common errors","**`Connection refused` on Open-WebUI startup.**\nOllama is not yet ready when Open-WebUI tries to connect. Wait 20 seconds and run `docker compose restart open-webui`. To avoid this on every restart, add a healthcheck on the Ollama service in `compose.yml`.\n\n**Streaming stops after 60 seconds.**\nYour reverse proxy applies a default HTTP timeout. Add `proxy_read_timeout 300s;` in the Nginx `location \u002F` block (or the equivalent `timeout` in Traefik). LLMs sometimes take several minutes to generate a long response.\n\n**`WebSocket connection failed`.**\nVerify that the `Upgrade` and `Connection` headers are correctly forwarded by the reverse proxy. Without them, SSE\u002FWebSocket streaming is blocked and responses don't arrive in real time.\n\n**SSO authentication returns `redirect_uri_mismatch`.**\nThe callback URL declared in your identity provider does not match what Open-WebUI sends. It must be exactly `https:\u002F\u002Fopenwebui.yourdomain.com\u002Foauth\u002Foidc\u002Fcallback` — with the full domain name, no trailing slash.\n\n**An SSO user can log in but has no access to any model.**\n`DEFAULT_USER_ROLE` defaults to `pending`: every new account, SSO included, waits for an administrator to activate it, and `ENABLE_OAUTH_SIGNUP` only governs account creation. Change their role to `user` in **Administration Panel → Users**, or set `DEFAULT_USER_ROLE=user` in the environment variables.\n\n**Unresponsive screen, `crypto.randomUUID is not a function` in the browser console.**\nOpen-WebUI is served over HTTP on a non-local domain or address: the browser only provides this function in a secure context (HTTPS or `localhost`). Finish the reverse proxy's TLS setup before testing the AI features.\n\n**Web search returns nothing.**\nSee the dedicated section below: test SearXNG on its own before blaming Open-WebUI.",{"type":36,"title":115,"body":116},"Troubleshooting: web search returns nothing","**Symptom.** Web search is enabled, but the conversation shows `No results found from web search` (a 404 error in Open-WebUI's log), or the model answers without having searched.\n\n**What that message says.** Open-WebUI did reach SearXNG, sent the query and received an empty list. A public case illustrates it (open-webui issue #32401, opened on 14 October 2026 after an upgrade to 0.12.0): the author suspected the new version, the maintainers first blamed the model, then, with SearXNG's own log in hand, found that DuckDuckGo answered with a CAPTCHA, Brave with \"Too many requests\" (engine suspended for 3 minutes each time) and Startpage with a redirect to its CAPTCHA. Every engine blocked, so zero results. According to the maintainers, those sites were blocking the IP address regardless of the upgrade. The issue was closed the same day with no fix on the Open-WebUI side, and the author ended up choosing the DDGS provider.\n\nThe method to keep: before blaming the version or the model, query SearXNG on its own.",{"type":53,"title":118,"steps":119},"Diagnose an empty web search",[120,123,126,129],{"title":121,"body":122},"Query SearXNG without Open-WebUI","From the VPS, run `curl -s 'http:\u002F\u002F127.0.0.1:8080\u002Fsearch?q=test&format=json'`, adjusting host and port to your setup (if SearXNG is only reachable over the Docker network, run the command from a container on that network). Three outcomes: a 403 error means `json` is missing from `formats`; an empty `results` list means the engines are failing; a filled list means SearXNG works and the problem is on the Open-WebUI or model side (see the tip below).",{"title":124,"body":125},"Read SearXNG's log","`docker compose logs --tail 200 searxng` shows what each engine answered. Look for lines that name an engine (duckduckgo, brave, startpage…) with a CAPTCHA, a refusal for too many requests or a timeout. An engine that comes back on every search with the same error is blocked for your VPS's IP address, which happens more readily to a data-centre address.",{"title":127,"body":128},"Enable or replace engines","In `settings.yml`, under `engines`, enable general-purpose engines that are not blocked: Open-WebUI's maintainers mention Google, Bing, Mojeek and Qwant. An entry `name: mojeek` with `disabled: false` enables an engine present in the default settings; with `use_default_settings: true` at the top of the file, you only list your differences. Restart with `docker compose restart searxng`, then replay step 1 until you get results. Enable several engines: a single active engine quickly falls into the block again.",{"title":130,"body":131},"Use a keyed provider if the IP stays blocked","If every engine fails, an API provider sidesteps the problem: Brave Search API, Tavily or Serper are chosen on the same administration screen. For Brave's free tier, set `WEB_SEARCH_CONCURRENT_REQUESTS=1`. The DDGS provider, which the issue author settled on, needs no key.",{"type":75,"body":133},"SearXNG returns results, but the assistant never searches? Since version 0.10.0 (late June 2026), native tool calling is the default mode: web search becomes a tool the model must call itself, and an old or small model skips it or writes a malformed call. Pick a recent model that handles tools and check that Function Calling is set to Native in the model's advanced parameters; the maintainers describe Legacy mode as unsupported. If the search succeeds but pages fail to load, look at `WEB_SEARCH_TRUST_ENV` behind an HTTP proxy, then `USER_AGENT`.",{"type":36,"title":135,"body":136},"Track the usage of a team instance","Knowing who consumes what quickly becomes a budget question once developers call the instance through the API. Today, four sources complement each other, each with a blind spot:",{"type":40,"title":138,"items":139},"The four measurement sources",[140,141,142,143],"**The Analytics dashboard** (administration settings, Analytics section): messages, input and output tokens, per model and per user, with group and period filters; since 0.12.4, ranking is by tokens. It is computed from the message history stored in the database: whatever is not stored there does not appear. `ENABLE_ADMIN_ANALYTICS=False` hides it.","**The personal view** (settings, Usage tab, since 0.11.0 in July 2026): each user sees their own activity, and nothing of anyone else's.","**The audit log**: off by default (`AUDIT_LOG_LEVEL=NONE`). With `AUDIT_LOG_LEVEL=METADATA`, Open-WebUI writes `audit.log` in its data directory (rotation at 10 MB) for requests authenticated by an `Authorization` header or a cookie: API calls therefore appear, with the requested model. To also get the tokens of each reply (since 0.12.4), remove `\u002Fchat` from `AUDIT_EXCLUDED_PATHS`, which defaults to `\u002Fchats,\u002Fchat,\u002Ffolders`. Avoid the `REQUEST` and `REQUEST_RESPONSE` levels, which record the content of conversations, and replay a test call to read the entry produced before building any count on it.","**The reverse proxy logs**: the simplest angle for volume. With Nginx's combined format, `awk '{print $7}' \u002Fvar\u002Flog\u002Fnginx\u002Faccess.log | sort | uniq -c | sort -rn | head` ranks the most-called paths; add `$request_time` to your `log_format` to spot slow requests. This log sees neither the user nor the tokens, and the `Authorization` header must never be recorded in it.",{"type":36,"title":145,"body":146},"What usage tracking does not do yet","The request for tracking that separates the interface from the API and attributes calls to each key is open on the project's repository: open-webui issue #21675, \"enh: analytics\", created on 20 February 2026 and still open on 7 November 2026, with about a hundred comments. The thread reports that an API user placed in a group does not appear in Analytics, and on 14 October a team whose developers mostly go through the API was still asking for that visibility. No date is announced there: do not plan anything around this feature.\n\nThe maintainers answer that a filter, meaning a Python function installed in the interface, can count requests, including API ones; a contributor points out that passthrough routes escape it. They file per-user or per-group caps under rate limiting, outside the Analytics topic. Reading the SQLite database `webui.db` directly remains possible on a copy, but its schema is not a contract and changes from one version to the next. A contributor has also published a third-party quota plugin: a function runs with the server's privileges, so read its code before enabling it.",{"type":75,"body":148},"Give each developer their own account and their own API key rather than a shared key: without a distinct identity, none of the four sources can attribute usage. If the API becomes the main channel, a gateway in front of Ollama that counts calls at the source (LiteLLM, already in the ServOrbit catalogue, offers virtual keys and spend tracking) is a lead worth testing before you adopt it.",{"type":36,"title":150,"body":151},"Secure access to the Ollama API","By default, Ollama listens on `0.0.0.0:11434` inside its container. The `compose.yml` configuration proposed above does not publish this port on the host — only Open-WebUI accesses it via the internal Docker network. This is the correct posture.\n\nIf you need to access the Ollama API directly (from an IDE, Jupyter notebook or external application), two options:\n\n1. **SSH tunnel**: `ssh -L 11434:localhost:11434 user@your-vps` — the API is accessible locally without public exposure.\n2. **Reverse proxy with authentication**: expose Ollama behind Nginx with `auth_basic` or a Bearer token, if you have clients that don't support SSH tunnelling.\n\nNever publish port 11434 directly on the public interface without authentication: the Ollama API has no native protection against unauthorised access.",{"type":75,"body":153},"To keep Open-WebUI up to date, change the image from `ghcr.io\u002Fopen-webui\u002Fopen-webui:main` to `ghcr.io\u002Fopen-webui\u002Fopen-webui:v0.13.0` (or the latest stable tag) in your `compose.yml`. The `:main` tag follows continuous development — handy for testing new features, less predictable in production. Check the release notes on GitHub before each update: some versions have introduced database migrations, others change default behaviours (native tool calling in 0.10.0), and the 0.12.0 notes recommend updating production deployments promptly for its security fixes.",{"type":40,"title":155,"items":156},"Advanced features to explore after deployment",[157,158,159,160],"**Pipelines and functions**: Open-WebUI allows writing Python functions that intercept the conversation flow — filters, context enrichers, connectors to external APIs.","**Custom models**: create pre-configured 'models' (system instructions, temperature, context) and share them with specific user groups.","**Image generation**: connect Open-WebUI to a local Stable Diffusion or ComfyUI instance to generate images directly in chat.","**Integration with external tools**: via the MCP (Model Context Protocol) protocol, Open-WebUI can call external tools — databases, REST APIs, web search.",{"type":75,"title":162,"body":163},"Official documentation","For advanced configuration and tool-specific options, refer to the \u003Ca href=\"https:\u002F\u002Fdocs.openwebui.com\">official Open-WebUI documentation\u003C\u002Fa>. This guide covers basic deployment and the most common configurations — parameters specific to your environment (LDAP integration, pipeline configuration, embeddings tuning) are in the project documentation.","A VPS ready for Open-WebUI and Ollama","Open-WebUI with Ollama requires a VPS with root access, Docker, and enough RAM to load your models. ServOrbit Cloud VPS offers the vertical scalability needed to move from a 7B to a 13B model without migration.","See Cloud VPS plans","\u002Fvps-cloud",[169,189,207],{"id":170,"slug":171,"slugs":172,"title":176,"excerpt":177,"readTime":178,"views":179,"isPinned":19,"noindex":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},9,"how-to-host-anythingllm-on-a-vps",{"fr":173,"en":171,"ar":174,"es":175},"heberger-anythingllm-vps","كيفية-استضافة-anythingllm-على-خادم-vps","como-alojar-anythingllm-en-un-vps","AnythingLLM on VPS: Full Guide with Pitfalls to Avoid","Host AnythingLLM on VPS: Docker, HTTPS, mandatory version pinning. :latest, Gemini v1.16 and Ollama Docker network pitfalls documented.",8,0,"2026-06-11T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-anythingllm-vps-poster.svg",{"categorySlug":187,"appSlug":188},"artificial-intelligence","anything-llm",{"id":190,"slug":191,"slugs":192,"title":196,"excerpt":197,"readTime":198,"views":23,"isPinned":19,"noindex":19,"publishedAt":199,"updatedAt":200,"category":201,"categories":202,"featuredImage":30,"bgImage":31,"posterImage":204,"relatedSolution":205},2,"deploying-dify-on-a-vps-ai-workflows-under-control",{"fr":193,"en":191,"ar":194,"es":195},"deployer-dify-vps","نشر-dify-على-vps-سير-عمل-الذكاء-الاصطناعي-تحت-السيطرة","desplegar-dify-en-un-vps","Deploy Dify on a VPS: Complete Guide from Installation to Plugins","Install Dify on a ServOrbit VPS: requirements, Docker Compose, offline plugins, known Docker limits, backup before upgrading, and troubleshooting.",15,"2026-02-11T00:00:00+00:00","2026-10-29T03:10:23+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[203],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-dify-vps-poster.svg",{"categorySlug":25,"appSlug":206},"dify",{"id":208,"slug":209,"slugs":210,"title":214,"excerpt":215,"readTime":216,"views":190,"isPinned":19,"noindex":19,"publishedAt":217,"updatedAt":218,"category":219,"categories":220,"featuredImage":30,"bgImage":31,"posterImage":222,"relatedSolution":223},177,"self-host-langfuse-on-a-vps-llm-observability-no-saas-bill",{"fr":211,"en":209,"ar":212,"es":213},"self-host-langfuse-vps","استضافة-langfuse-على-vps-مراقبة-llm-بلا-فاتورة-saas","alojar-langfuse-en-un-vps","Self-Host Langfuse on a VPS: LLM Observability, No SaaS Bill","Self-host Langfuse on a VPS — trace every AI call, evaluate prompts, track LLM costs. Full guide: installation, nginx, TLS, Python\u002FJS SDK integration, troubleshooting.",11,"2026-07-12T00:00:00+00:00","2026-11-04T16:30:26+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[221],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-langfuse-vps-poster.svg",{"categorySlug":187,"appSlug":224},"langfuse",true,1794270462672]