Tabby Self-Hosted Review: Six Months Running on My Homelab

I installed Tabby on my homelab server in August and have been running it every day since. If you’re looking at self-hosted code completion and wondering whether Tabby is worth the hardware investment and setup friction, I can give you the answer: it depends on what you actually do, and what you’re comparing it to. It’s not the invisible perfect thing the demo suggests, but it’s also not a waste of time.

What Tabby Is and What I Set Up

For the three people who haven’t heard of it: Tabby is a self-hosted code completion engine. You run it on your own hardware, point your editor at it (VS Code, Vim, JetBrains IDEs, Emacs), and it feeds you completions as you type. No code leaves your network. No monthly bill to GitHub.

I deployed it using Docker Compose on an older Dell PowerEdge with an RTX 3060 12GB. The setup was straightforward if you’ve done this before—Docker, bind mount some volumes, point it at a model, wait for it to download. I went with the default StarCoder 7B quantized variant. The whole process from “never run this” to first completion took about an hour, not counting the 4GB model download.

version: '3.8'
services:
  tabby:
    image: tabbyml/tabby:latest
    ports:
      - "8080:8080"
    volumes:
      - tabby_data:/root/.tabby
    environment:
      - TABBY_BIND=0.0.0.0
      - TABBY_PORT=8080
    command: serve --model StarCoder-7B
    restart: unless-stopped
volumes:
  tabby_data:

I installed the VS Code extension and pointed it at my server. The extension tries to be invisible—you type, it suggests. That part worked immediately.

What Felt Actually Good for the First Month

The honeymoon period was real. Single-line completions were snappy. Autocomplete for boilerplate—try/except blocks, function signatures, import statements—came back in under a second most of the time. Writing Python felt faster. You notice that.

Multiline completions were weird and often wrong, so I left that off. The extension has a setting for it, and I never found it useful. But the one-liner stuff worked well enough to make me reach for code less often.

What surprised me: repository context actually matters. Tabby has a feature where you can index your local codebase and it tries to use that context for better completions. I set it up on a small project (maybe 20K lines), and the suggestions did feel more aligned with my actual patterns. Not mind-blowing, but definitely there. It’s not reading your whole codebase like Copilot might, but it’s aware of your naming conventions and common structures.

The privacy aspect was genuinely nice. I code on things I don’t want floating around in some vendor’s telemetry stream. That alone made the setup worth the effort, at least psychologically.

Where It Started to Irritate Me

Around month two, the friction crept in. First: the model isn’t that good. StarCoder 7B is fast and light, but it’s not bright. It would suggest things that are syntactically correct but logically wrong. Variable names it made up. Functions that don’t exist in the stdlib. You learn to ignore most suggestions and just use it for the 20% of cases where it’s actually helpful.

That means you’re back to reading suggestions critically. You have to check what it’s offering. After a few weeks, that friction cost outweighs the time saved on boilerplate. You start hitting escape without looking, which defeats the purpose.

Second: the repository indexing doesn’t automatically update. You have to manually re-index when your codebase changes. For active projects, that means either running the index regularly or just accepting stale context. I set up a cron job to re-index every night, but the whole thing feels bolted-on. Copilot just knows. Tabby requires you to remember to tell it.

Third, and I’ll be honest here: GPU memory management is fiddly. The RTX 3060 is 12GB. With Tabby at 7B parameters quantized, it’s using about 4.5GB at idle, more during active completion. But inference isn’t always fast. When I’m writing quickly or when the context window gets big, the model can stall. I’ve sat there typing, watching the suggestion latency creep from 500ms to 2000ms. Sometimes it falls back to CPU and becomes glacial.

It’s not broken. It’s just not transparent. The extension doesn’t tell you the model is struggling. It just gets slower. You notice it, but there’s no dashboard feedback like “yeah, we’re out of VRAM, processing on CPU now.”

The Maintenance and Monitoring Question

After six months, Tabby is stable. The Docker container restarts on reboot. The model loads. Extensions connect. It doesn’t crash. But it also doesn’t alert me to anything.

I have Prometheus collecting basic metrics from it, mostly out of habit. CPU usage stays low. GPU utilization bounces around 10-30% depending on activity. The container uses a steady 2.5GB of RAM for overhead. None of this is surprising or alarming.

What is surprising: I haven’t had to update the model or the server since March. The extension gets minor updates, but nothing mandatory. It’s the opposite of the cloud tools, which change their behavior without asking. Tabby just sits there doing the same thing month after month.

That’s good for stability and bad for novelty. The model hasn’t improved. The suggestions today are the same quality as six months ago. That wasn’t what I expected.

Comparing to What Else Exists

I should say what I’m using it against. Before Tabby, I tried Copilot for about two weeks (the free version, GitHub’s service). I also looked at Cody (Sourcegraph’s tool) and Brief (Hugging Face’s offering, though they discontinued it). For context, I write mostly Python and some JavaScript, so those are my test cases.

Copilot is definitely smarter. The suggestions are better. They’re contextually relevant more often. But you’re paying, and your code is being sent somewhere. If that bothers you, it matters.

Cody is interesting if you want context retrieval built in, but it also talks to their servers. And it’s expensive if you want the good features.

Compared to running nothing: Tabby saves me time on repetitive boilerplate. Compared to cloud Copilot: Tabby is slower, less accurate, and local. If you are paranoid or poor or both, Tabby wins. If you want the best tool and don’t care about the vendor, Copilot wins.

I’m somewhere in the middle. I wanted to run something on my own hardware and see what the real limitations are. Now I know.

Real Talk on Whether to Install It

Here’s the honest version: install Tabby if you have hardware lying around and you actually care about code privacy. Don’t install it if you’re looking for a free Copilot replacement that works just as well. It doesn’t.

The setup is not hard, but it’s not automatic. You need Docker, some familiarity with networking, enough GPU memory (8GB minimum if you want it to not feel awful), and patience to let it index your code.

Once it’s running, it does the job it says it does: it offers completions, they’re local, and it doesn’t phone home. The completions are usually half-useful, sometimes frustrating, occasionally magical. You get what you pay for in terms of accuracy and latency.

The maintenance burden is minimal. It doesn’t break. It doesn’t require you to understand machine learning. You just run it and use it or don’t. That’s the real win for me: it’s boring infrastructure that works. Not perfect, not exciting, but stable.

If you’re the type who likes to own your tools and you’ve already got the hardware budget, it’s worth trying. If you’re coming from Copilot or looking for the best possible code completion, you’re making a trade-off. Know what you’re trading.

FAQ

Can I run Tabby on a GPU with less than 8GB of memory?

Technically yes, but it will be slow. Smaller quantized models like StarCoder-3B fit in 4-5GB, but inference will stall under load. 8GB is the practical minimum for the 7B models that actually feel responsive.

Does Tabby work with Rust or compiled languages?

It works the same as with Python—it gives suggestions. Whether they’re good is another question. Rust has stricter type constraints, so the model’s mistakes are more obvious. Completions are better for dynamic languages than compiled ones.

Do I have to re-index my codebase every time I change a file?

No, but Tabby won’t know about your changes until you do. There’s no automatic watching. You can set up a cron job to re-index periodically, or you can do it manually through the web UI. For active projects, nightly re-indexing is the practical approach.

What happens if my Tabby server is offline?

The VS Code extension will keep working offline for a short period (it has some cached suggestions), but new completions won’t load. You’ll see a red indicator in the editor. Most people just switch to writing without completions until the server comes back.

Is Tabby faster or slower than Copilot?

Tabby is usually slower. Local inference introduces latency that cloud services don’t have. You’re trading speed for privacy and control. Expect 500ms to 2000ms depending on your hardware and what you’re asking for.

Explore Tabby in our AI Homelab Toolkit.