Four ways to install an open-source AI tool (and which one to pick)

There are four ways to install an open-source AI tool: a desktop app, a single
terminal command, Docker, and an editor extension. They are listed here roughly
from least to most technical, and all four are covered below.
This is not "how to install tool X" — there are enough of those. It is the piece
that is missing before those: which of the four paths you should open at all.

Path 1 — Desktop app: download, install, double-click

The shortest route. You download a file, double-click it, and the app opens. No
terminal, no commands.
AnythingLLM is the best example: a local assistant you can point at your own
documents. The desktop build runs on Windows, macOS and Linux, with separate
64-bit x86 and ARM downloads for Windows.
Two things from the official docs worth knowing before you install: it is built
for regular Home/Pro user accounts and targets Windows 11 — Enterprise or Server
editions may not work — and you should pick "only for me" rather than "all users":
the docs say a machine-wide install causes problems and is not supported.
It has a built-in local LLM engine (powered by Ollama), so you do not need to
install a separate runner. The pieces needed to use an NVIDIA or AMD card are
pulled in during setup.
For images, the second example is Upscayl: it enlarges small, blurry photos.
It has one hard requirement — a Vulkan-capable
GPU. The README notes it does not work on most integrated graphics, but adds that
trying costs nothing. There are .exe, .dmg (or brew install --cask upscayl
on macOS), AppImage, Flatpak and Snap builds.
Where this path stops: you are stuck with the experience that shipped. Anything
multi-user, or a chat widget embedded in your own site, exists in AnythingLLM only
in its Docker build.

Path 2 — One command in the terminal

Here you paste one command and press Enter. If you have never opened a terminal:
Win + X then Terminal on Windows, Cmd + Space then Terminal on macOS,
Ctrl + Alt + T on Linux. Do not close the window while it runs — the download is
happening there.
Ollama is the standard example: it pulls and runs open models. On Linux the
install is one line:

curl -fsSL https://ollama.com/install.sh | sh

If the server is not already running afterwards, start it with ollama serve.
Pulling a model is one command too. The official quickstart uses Gemma 4 E2B:

ollama pull gemma4:e2b

That download is about 7.2 GB, and the docs recommend 8 GB of available VRAM (or
unified memory on a Mac). With less, Ollama falls back to system RAM and responses
get slower. It also exposes a local API you can hit from your own scripts:

curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{"model":"gemma4:e2b","messages":[{"role":"user","content":"hi"}],"stream":false}'

The second example is the agent we run every day: Hermes Agent. On Linux and
macOS it is one line;
on Windows there is a separate PowerShell command that runs natively, without WSL:

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

Setup lands in %LOCALAPPDATA%\hermes, where settings, memory and sessions live.
Two things we hit: some antivirus products quarantine the bundled uv.exe as a
false positive — it is the tool that manages the Python environment. And after one
update the desktop app stopped launching until the next release, so we now run
hermes backup before updating; it packs settings, memory and sessions into a
single zip.
If you write code, the third example is OpenCode (docs):

curl -fsSL https://opencode.ai/install | bash
# or, with Node installed
npm install -g opencode-ai
# or on macOS/Linux via Homebrew
brew install anomalyco/tap/opencode

Where this path stops: the commands are OS-specific. A curl … | bash line
written for Linux and macOS does not work on Windows as-is. Check the README for a
separate PowerShell command or a downloadable installer before you start.

Path 3 — Docker

Docker packs an application with everything it needs into an isolated box. It is
the right tool for browser-based panels and for anything that must keep running on
a server. The app comes up with one command, but you install Docker first. On
Windows that means Docker Desktop, which offers a per-user mode that does not need
admin rights and uses WSL 2 underneath.
The best illustration is the automation platform n8n.
n8n's Docker page
(now marked outdated in favour of Docker Compose) still documents this quick-trial
command — first create the volume, then run the container:

docker volume create n8n_data
docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="Europe/Istanbul" \
  -e TZ="Europe/Istanbul" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n

The editor opens at http://localhost:5678. Do not drop -v n8n_data:/home/node/.n8n:
that volume is what survives when the container is removed. The docs are explicit
that this directory holds encryption keys and logs, not just the database — losing
it can lock you out of your own credentials. For anything beyond a local trial, n8n
recommends Docker Compose.

Careful with older tutorials. You will find this command around with the image
docker.n8n.io/n8nio/n8n and without the docker volume create step. Follow the
form above, or better, the Docker Compose setup.
For your own chat UI there is Open WebUI, which puts several models behind one
screen and lets you chat with uploaded documents. Generate a secret key once and
save it:

openssl rand -hex 32

Then paste that saved value into the command:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  -e WEBUI_SECRET_KEY=your-saved-key \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

Then open http://localhost:3000. Three flags earn their place:

• -v open-webui:/app/backend/data — chats, users and settings live here. The docs say to never run without it.
• --add-host=host.docker.internal:host-gateway — lets the container reach Ollama running on your machine.
• -e WEBUI_SECRET_KEY=… — use the same saved key every time. If the key changes when the container is recreated, everyone gets logged out. For GPU support there is the :cuda tag plus --gpus all (which needs NVIDIA's container toolkit on Linux or WSL). If you would rather not install Ollama separately, the :ollama tag bundles both. And if you want to avoid Docker entirely, the Python path works — with two caveats from the docs: pip install open-webui must be followed by open-webui serve, and the supported interpreters are Python 3.11 and 3.12 — not 3.13, where installs fail or break at runtime. RAM and disk: there is no fixed number. The space goes to images and models, each several gigabytes, and memory scales with how many services run at once. ## Path 4 — Editor extension If you write code, this is the natural fit: it installs into your editor and works in the same window as your files. Cline and Kilo Code are two examples, both from the VS Code Marketplace, and both also have a JetBrains plugin and a CLI (npm i -g cline and npm install -g @kilocode/cli), so they work from the terminal too. The thing to understand about this path: the extension is the interface, the model comes from somewhere else. After installing Cline you connect either a local model or a cloud provider with an API key. Kilo Code shortens that step — per its README you can start without an API key by signing in and reaching the models at the provider's price. Either way the install is free and the cloud model is what you pay for as you use it. ## Which path is yours? | How comfortable you are | What you want to do | Pick | |---|---|---| | You do not want to type commands | Chat with your own documents, upscale photos | Path 1 — desktop app | | You can paste one command | Pull and run a model, install an agent | Path 2 — terminal | | You want a service reachable from a browser | Automation flows, a chat panel for a team | Path 3 — Docker | | You write code and live in your editor | An assistant that works on your project files | Path 4 — extension | Hardware is a separate threshold. If you run models locally, your GPU memory is the deciding factor — it works on CPU too, just slowly. ## Where does the model come from? Most of these tools do not ship a model. What you installed is a runner or an interface; the model is a separate choice, and there are two. Local. The model downloads to your machine, works offline, and your data never leaves it. The price is hardware: the file takes gigabytes of disk and GPU memory while it runs. Ollama and LM Studio (lmstudio.ai) are the two common runners. Models live on Hugging Face, where each page lists the license, file sizes and how to run it — and many have a browser demo in Spaces. Checking that demo is the cheapest way to find out whether a model is useful before downloading gigabytes of weights. API. The model runs on someone else's server and you send requests. No hardware, but you pay per use and your data goes to that server. OpenRouter gives you many models behind one account, free ones included — though which models are free shifts over time, so check its own site rather than any price list you find in a post, this one included. ## Read the license before you deploy "Open source" does not mean "anything goes", and it matters most if you are putting this in a company. Four groups cover most of what you will meet:
• MIT and Apache-2.0 — near-unconditional. Use, modify, ship commercially.
• GPL-3.0 — use and modify freely, but distribute a modified version and you must publish its source.
• AGPL-3.0 — the same, extended to the network. Offer a modified version as a hosted service and you still owe the source.
• Restricted licenses — source-available but with limits: separate terms for commercial use, or commercial use forbidden outright. Read these carefully. The license lives in a LICENSE file at the root of the project's repository. One more trap: a tool's core can be MIT while its enterprise features are licensed separately. If this is for work, having someone read it is slow, and still cheaper than the problem it prevents. ## Do not expose the panel you just installed A panel you use at localhost is reachable only by you. The same panel on a server with its port open is reachable by anyone. A login screen alone is not enough. We learned this the expensive way. During a security pass on our own server we had to move a service that was still directly reachable on its port behind a reverse proxy. If you are deploying to a server, apply these before you start:
• Do not expose an admin panel straight to the internet.
• If you must, put it behind a reverse proxy and turn on authentication first.
• Change or remove default credentials, and close whatever accepts new signups.
• Keep it updated. A panel installed and forgotten for weeks causes more incidents than a mistake made during setup. ## So what do you do?
• Decide what you actually want: chat over documents, model experimenting, automation, or code.
• Pick your path from the table and start with one tool. Install three at once and you will lose track of which one is doing what.
• If you are going local, choose a model that fits your GPU before downloading anything, then check its Hugging Face page.
• Check the license, especially for work.

5. If it is going on a server, apply the security list before setup, not after.

Adapted from the Turkish guide Açık kaynak yapay zeka araçları nasıl kurulur.
The same site has a directory of open-source AI tools, with each project's license
taken from its own repository. It is in Turkish — the four install paths above are
not language-specific.