curxy: a Deno proxy that lets Cursor reach a local Ollama server
Simple proxy worker for using ollama in cursor
At a glance
- What is it?
- curxy is a small Hono-based worker that forwards OpenAI-shaped requests from the Cursor editor to an Ollama instance running on your machine, exposing it through a cloudflared tunnel. The design is simple and the scope is narrow, which is exactly why it works.
- Who is it for?
- Adopt curxy if you already run Ollama locally, want Cursor to talk to it, and are comfortable with Deno and a cloudflared tunnel exposing a local port. Skip it if you need a hosted, multi-user gateway, TLS termination you control, or a documented rollback path, none of which the README covers.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Cursor-to-localhost problem curxy exists to solve
Cursor's model configuration lets you override the OpenAI base URL and add model names. The README explains why that alone is not enough: when you use LLM prediction in the editor, the editor sends data to the official Cursor server, and that server is what forwards the request onward. If you point the base URL at localhost, the Cursor server has no route back to your machine. The request leaves your laptop and dies.
curxy inserts a reachable hop in the middle. You run it next to Ollama, it opens a Cloudflare tunnel to a local port, and you paste the resulting public URL into Cursor with /v1 appended. The audience is narrow: developers who already have Ollama installed, want Cursor's chat or completion features backed by a local model, and do not mind running a Deno process alongside their editor.
How the proxy worker forwards requests to Ollama
The repository is small: main.ts, proxy.ts, util.ts, deno.json and deno.lock. The topics list hono, so the HTTP layer is Hono running on Deno, and proxy.ts is where the forwarding logic lives. The README describes the behaviour plainly: it is a server that forwards requests to the Ollama server and returns the response.
The startup output shows the shape of the runtime. curxy binds to 127.0.0.1 on a port it picks (62192 in the README example), then starts a cloudflared tunnel to that address and prints the trycloudflare.com URL. That URL is the only thing Cursor needs. The optional OPENAI_API_KEY environment variable turns on key-based access restriction, which matters because a trycloudflare hostname is publicly resolvable while the process is running. The README does not document request rewriting, streaming behaviour, or which OpenAI endpoints are handled; proxy.ts is the place to read if you need those answers.
Installing curxy and pointing Cursor at it
The requirements are Deno and a running Ollama server. Start Ollama first, then launch curxy from JSR. The -A flag grants all permissions, which the tunnel and network binding need.
deno run -A jsr:@ryoppippi/curxyIf you want to restrict who can reach the proxy, set OPENAI_API_KEY. The README shows the key passed inline before the same command.
OPENAI_API_KEY=your_openai_api_key deno run -A jsr:@ryoppippi/curxyOn startup you should see a line like Listening on http://127.0.0.1:62192/ followed by a cloudflared line and a Server running at: https://<random>.trycloudflare.com address. Copy that public URL, append /v1, and paste it into the Override OpenAI Base URL field in Cursor's settings. Then add the Ollama model names you intend to use to the Model Names section. A help message is available with deno run -A jsr:@ryoppippi/curxy --help.
Where curxy stops being the right tool
The tunnel URL is the weak point. A trycloudflare hostname is public for as long as the process runs, and the README's only access control is OPENAI_API_KEY. If you launch without that variable, anyone who learns the hostname can send requests to your Ollama instance. That is a real exposure, not a theoretical one, because the hostname is printed to your terminal and travels wherever you paste it.
The project is also single-user by design. There is no authentication layer beyond the API key, no rate limiting, no multi-tenant routing, and no documented way to run several backends behind one endpoint. If you need a shared gateway for a team, curxy is the wrong shape. Finally, the README does not document rollback, log retention, or what happens when cloudflared drops the tunnel; you would be reading proxy.ts and main.ts to learn that, and the documentation is silent on all three.
curxy compared with running a reverse proxy yourself
The obvious alternative is to skip curxy and expose Ollama through a general-purpose tunnel or reverse proxy you configure yourself, for example cloudflared or ngrok pointed directly at Ollama's port, or a small nginx or Caddy config on a host with a stable address. The difference is in what each one does for you.
A raw tunnel forwards everything on the port, including Ollama's native API surface, and leaves URL shaping, key checks and the /v1 prefix to you. curxy packages that shaping: it starts the local listener, starts the tunnel, and gives you a URL that Cursor's OpenAI-compatible field accepts after appending /v1. It also reads OPENAI_API_KEY and enforces access on that basis, which a bare tunnel does not. The trade-off is control. With your own proxy you choose TLS, hostname stability and logging; with curxy you get whatever the trycloudflare URL and the bundled Hono app provide, and no more.
Maintenance, licence and upgrade cost
curxy is MIT licensed, so you can fork, vendor or modify it, and the repository includes the LICENSE file. The last push to main was on 2026-09-13, two days before this writing, so the codebase is being touched. The most recent tagged release in the list is v0.3.4 from 2026-05-26, which means the gap between tags is wider than the gap between commits; if you pin versions, pin the tag, not the branch.
Upgrade cost is low in absolute terms because the surface is small, but it is not zero. The install path is deno run against a JSR specifier, so an upgrade means either re-running without a version pin or bumping the specifier. There is no documented migration guide between releases, and the README does not describe a configuration file, so most of what you would need to re-check after an upgrade lives in proxy.ts and main.ts. Nothing here constitutes legal advice; read the MIT text in LICENSE yourself.
Editorial conclusion
Adopt curxy if you already run Ollama locally, want Cursor to talk to it, and are comfortable with Deno and a cloudflared tunnel exposing a local port. Skip it if you need a hosted, multi-user gateway, TLS termination you control, or a documented rollback path, none of which the README covers. Before wiring it into Cursor, verify that OPENAI_API_KEY is set if the endpoint is reachable from the public internet, and confirm the /v1 suffix is appended to the tunnel URL.
Frequently asked questions
What is curxy and what does it do?
curxy is a proxy worker for using Ollama in Cursor. It forwards requests to the Ollama server and returns the response, exposing a public URL through a cloudflared tunnel so the Cursor server can reach your local model.
How do I install and start curxy?
Install Deno and start your Ollama server, then run deno run -A jsr:@ryoppippi/curxy. The README notes you can set OPENAI_API_KEY to limit access, and that deno run -A jsr:@ryoppippi/curxy --help prints a help message.
What URL do I put into Cursor's Override OpenAI Base URL field?
Take the public URL that curxy prints, the one hosted by Cloudflare, and append /v1 to it. The README instructs entering that value into the Override OpenAI Base URL section of the Cursor editor configuration.
Why can't Cursor talk to my local Ollama server directly?
The README states that when you use LLM prediction in Cursor, the editor sends data to the official Cursor server, which then forwards it. Because that server cannot reach your localhost, a proxy worker is needed to forward the data to the Ollama server.
Community notes