Self-hosted AI without giving up model choice
ai.diy is a self-hosted AI chat workspace for people who want to choose their infrastructure as well as their model provider. Run the production build on a Node.js server or Docker Compose, then keep your workspace data in the browser.
- Deploy
- Node.js, Docker Compose, or a Vercel preview
- Data model
- Browser-local settings, chats, Canvas, and knowledge
- Provider access
- BYOK cloud providers or local endpoints
What self-hosting means in ai.diy
A self-hosted ai.diy instance is the workspace server you run and maintain. It serves the app and relays provider requests, but it is not a hosted model company and does not supply model credits.
The browser remains an important part of the architecture: chats, settings, provider keys, Canvas artifacts, memory, knowledge-base indexes, and usage events are stored locally by the client. That is useful for a personal workstation, a private team deployment, or a developer evaluating multiple providers without moving between apps.
Know the trust boundary
| Layer | What it handles |
|---|---|
| Browser | Workspace state, keys, local knowledge, and Canvas artifacts |
| Your relay | App delivery, model discovery, request forwarding, and optional rate limits |
| Chosen provider | The prompts, files, and tool context needed to produce the model response |
Who should self-host it?
Self-hosting is a good fit when you want an auditable deployment, browser-local persistence, control over operational logs, or a single interface for cloud and local models. It is also useful when a hosted demo is not the right place for work data.
It is not a substitute for provider security review. A public deployment needs authentication or network controls, HTTPS, sensible logging, and server rate limits. Read the project deployment notes before exposing it beyond a trusted network.
A practical setup path
- 1
Clone and install
Use the repository and lockfile so the production build uses the tested dependency graph.
git clone https://github.com/Cubinghackerz/ai.diy.git cd ai.diy npm install - 2
Build and serve
Run the production server on the port and host boundary you control.
npm run build && npm start - 3
Connect a provider
Open Settings, choose a cloud or local provider, test the connection, and keep the model selection that fits the task.
Questions people ask
What does self-hosting ai.diy control?
You control the Node.js or Docker deployment, its logs, network boundary, access controls, and hosting provider. The selected model provider still receives prompts and files when you use a cloud endpoint.
Does self-hosting make cloud model requests private?
No. Self-hosting controls the ai.diy relay and infrastructure, but a cloud provider still processes the request. Use an authorized local endpoint such as Ollama or LM Studio when the model must stay on your network.
Can I run ai.diy without putting LLM keys in server environment variables?
Yes. ai.diy is designed for bring-your-own-key use. Provider keys are entered in the browser and relayed per request; configure rate limits and access controls before exposing a deployment publicly.