A Self-Hosted Grok Bot Alternative Where Your AI Team Lives on Your Own Server

A self-hosted alternative to Grok Bot just showed up on r/PromptEngineering, and the idea behind it is worth a look. Yesterday a clever build shipped, and the twist is where it gets interesting.

What’s new

Grok Bot runs your agents in its cloud. u/ldrx built 5dive, a CLI that runs a whole company of AI employees on your own server. They’ve been running it since April, so this isn’t a weekend demo. The core is MIT licensed and built from bash, systemd and sqlite. That’s a deliberately boring stack, and boring is a feature here. There’s no heavy framework to babysit, no container orchestration to learn, and nothing exotic to debug at 2am. It’s lightweight enough for a tiny 1GB box, which means the cheapest VM from almost any provider is a realistic home for your whole team. Because it’s your server, your prompts, your files and your agent logs stay on hardware you control. If you’ve ever hesitated to hand a hosted bot your client work or internal docs, that alone may be the reason to try this.

The twist

Each agent runs as its own separate Linux user. There’s no custom sandbox layer. It uses the isolation Linux already gives you. In practice that means file permissions, home directories and process ownership do the work, the same way they’ve kept human users apart on shared servers for decades. One agent can’t casually read another agent’s files, and a misbehaving one is easy to spot with the tools you already know, like ps and top.

It also doesn’t lock you into one model or one tool. You can mix Claude Code, Codex, Grok, agy, Hermes, OpenClaw, Pi and more on the same team. They run on your own plans, API keys or local LLMs. So if you already pay for a Claude subscription and a Codex plan, you don’t pay twice. You point the team at what you own, and you can put cheaper or local models on routine jobs while saving the stronger ones for hard problems.

It’s also set up like a real team, not a pile of chat windows. There’s an org chart, a shared backlog and handoffs between agents. Independent graders check the work, and human approval gates sit before anything important happens. The author says hiring a new developer on Codex is a single message. Think of it like this: one agent drafts, another reviews, a grader scores the result, and you only get pinged when a decision truly needs a human.

Mini-workflow to try it

  • 🛠️ Spin up any Ubuntu VM. The author says a small one is enough, so don’t overthink the size. A cheap 1GB instance is fine for a first run.
  • 🛠️ Run the one-command setup. Grab the exact command from 5dive.ai/self-host. Read the script before you run it, as you should with any install one-liner on a fresh box.
  • 🛠️ Connect the web app from that same page. Chats can be end-to-end encrypted with one switch on your server, so flip it on from the start rather than retrofitting it later.
  • 🛠️ Hire your first agent on the harness you already pay for, then hire a second one on a different harness. Giving them different jobs, say a builder and a reviewer, shows you the handoff flow fast.
  • 🛠️ Put an approval gate in front of anything you wouldn’t want an agent to do unsupervised. Deleting files, sending emails and spending money are good first candidates.

Pro tips

  • Start with one or two agents. Watch how the backlog and handoffs behave before you scale up. Give them a small, real task, like triaging a folder of notes, and see how the work moves between them.
  • Use the independent graders. An agent checking its own work is the weak spot of most agent setups, and a separate grader helps there. Ideally, run the grader on a different model than the one that did the work, so it doesn’t share the same blind spots.
  • If you share the box with other things, check how resources are split between agents. A commenter asked how limits per agent work on a 1GB machine, and I didn’t see an answer in the post. Test it yourself before you trust it with anything heavy. Since each agent is a normal Linux user, standard tools like systemd resource controls and ulimits are the obvious places to start, but verify that rather than assuming it.
  • Keep backups of the sqlite file. It holds your backlog and team state, and a quick copy on a schedule is cheap insurance.

The trade-off

The author is upfront that Grok Bot has the better native apps. This one is a web app for now, with Android and iOS listed as coming soon. If you want polish on your phone today, that matters. If you want control over where your agents run and which models they use, it matters less. You’re also taking on the work of running a server, including updates and security basics, which a hosted product handles for you. That’s a fair price for some people and a dealbreaker for others.

Repo: github.com/5dive-ai/5dive
Self-host guide: 5dive.ai/self-host

Call to action

⚓ Try it on a throwaway VM this weekend and tell me what broke. If you’ve already run agents as separate Linux users, I’d like to hear how you handled resource limits.

i built a self-hosted Grok Bot alternative
by u/ldrx in PromptEngineering

Scroll to Top