Start

Quickstart

The first path is the one to take: EDI on your own machine, with a local model, needing no account anywhere. The second is putting it on a server, which is the same thing plus a reverse proxy.

Prerequisites

  • Python 3.11 or newer, and Node 20 or newer.
  • A model. Either Ollama running locally, or an API key from any provider in Choosing a model.

Local, with no accounts

This is the default path, and the one most people should stay on. Workspaces go in a local SQLite file, the model runs on your machine, and nothing your sheet contains crosses the network.

1. Backend

git clone https://github.com/illeniall239/EDI.git
cd EDI

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate

pip install -r backend/requirements.txt
pip install langchain-ollama==0.3.3

Pull a model and start Ollama, if it is not already running:

ollama pull qwen2.5-coder:7b
ollama serve

Check that the model can do the job before going further:

EDI_LLM_PROVIDER=ollama python backend/check_model.py

Then start the backend:

EDI_LLM_PROVIDER=ollama uvicorn main:app --reload --port 8000 --app-dir backend

2. Frontend

cd edi-frontend
npm install
echo "BACKEND_ORIGIN=http://127.0.0.1:8000" > .env.local
npm run dev

Open http://localhost:3000. BACKEND_ORIGIN is read server-side by next.config.ts, which proxies /api/* to the backend so development is same-origin, exactly as production is.

It is not a NEXT_PUBLIC_ variable, deliberately. Those are inlined into the browser bundle at build time, so a stale one keeps redirecting a deployed site at a host nobody remembers configuring, long after the config that set it is gone.

3. Check it came up

curl localhost:8000/api/health

The reply names the provider and model it resolved, and where workspaces are being kept. If something is misconfigured, this is where it says so rather than failing quietly:

{
  "status": "healthy",
  "llm_config": { "provider": "ollama", "model": "qwen2.5-coder:7b", ... },
  "store": { "backend": "sqlite", "location": ".edi-data" }
}

Deployed

Two long-running processes and a way for the browser to reach both. That is the same two commands as above plus a reverse proxy sending /api/* to the backend and everything else to Next. One origin, so no CORS.

What the host has to give you is a disk. Workspaces are a SQLite file under EDI_DATA_DIR, so it needs to be writable and to survive a restart. Serverless platforms give you neither, and no two of their instances share one, so the app does not run there.

Self-hosting goes through both: where workspaces live, what a public URL needs in front of it, and how big a sheet the grid will open.