Linchpin
Open-source, self-hostable runtime for managed AI agents
Start new thread
NIkhil Aourpally

Linchpin - Open-source, self-hostable runtime for managed AI agents

by
Linchpin
•
Linchpin is an open-source, self-hostable runtime for managed AI agents. Apache-2.0. One `docker compose up` and you get a full agent platform — REST + SSE API, per-session Docker sandbox, MCP tools, encrypted vaults. Bring any cloud model via OpenRouter, or local via Ollama.

Add a comment

Replies

Best
NIkhil Aourpally
Maker
📌
Hey PH 👋 — Nikhil, one of the makers. Every time Devin, Manus, or Operator launched, the top comment on HN was some variant of "is this open source?" The answer kept being no. So we built Linchpin. It's the runtime layer under a managed agent — the thing you run on a VM that hosts the agents, manages the per-session Docker sandbox, persists the event log, and exposes a clean HTTP/SSE contract. Closer to "LangGraph + your-own-FastAPI + your-own-docker-py + your-own-event-log, but pre-wired" than to a library. What's actually there in v0.1: • Agents (versioned configs), environments (container templates), sessions • 8 built-in tools (bash/read/write/edit/glob/grep/web_fetch/web_search) • MCP via stdio, custom HTTP tools • Fernet-encrypted credential vaults • ~3k LOC Python + a small React console • Single VM, ~4 GB RAM minimum Honest tradeoffs: single-tenant single-user today. No observability dashboards yet. No SSO/RBAC. Deliberate cuts to keep v0.1 small and readable. If you've tried self-hosting OpenHands, OWL, Aider, etc. as a control plane vs. a CLI — would genuinely love to hear what you wished existed at the platform layer. Repo: https://github.com/linchpinhq/li... Site: https://linchpin.work Arch: https://linchpin.work/architecture
Rivra

Managed AI agents often feel like a black box, so a self-hostable runtime is a breath of fresh air for privacy-conscious teams. What’s the resource overhead like for running a single agent instance on a local server?

NIkhil Aourpally
Maker

@rivra_dev 

Thanks! Rough breakdown for a single agent instance:

* Runtime itself (Node + small Postgres for sessions/event log): ~500 MB idle

* Sandbox container per task: ~300 MB while a run is active, freed when idle

* Model calls go out to a provider, so no local GPU or inference RAM

I would love to hear your feedback once you try it out!

Shwet Gaur

As a CS student who's been trying to self-host agent setups, the gap between 'here's a library' and 'here's a running platform' is genuinely painful. One thing I'm curious about is that how do you handle the agent going rogue inside the Docker sandbox? Like is there a kill switch or resource cap per session, or is that still on the roadmap?

NIkhil Aourpally
Maker

@shwet_gaur 

Honest answer, partial today, hardening on the roadmap. Worth being upfront because you'd feel this on day 1 of a self-host.

Today (v0.1):

- Manual kill via DELETE /v1/sessions/{id}, cancels the orchestrator and destroys the container.

- TTL reaper, set ttl_seconds at session create; expired sessions get terminated every 60s.

- Soft interrupt, a user.interrupt event stops the model loop between tool calls (doesn't kill the container).

- Network isolation, two Docker networks: linchpin-none (no egress) and linchpin-open.


What's missing is the actual resource caps:

- No CPU / memory / PID / disk limits on the sandbox container.

- No exec timeout, a shell command in the sandbox can run forever.

- No per-session iteration or token budget beyond TTL.

So today: trusted-environment self-host. A misbehaving agent can pin CPU or fill RAM until the host complains. The kill switch works, but only if you (or the TTL) pull it.

Sandbox hardening, cgroup caps, exec deadlines, a hard-kill interrupt, optional iteration budgets, is on the roadmap. Putting up a numbered release doc for it this week and linking it from the README so it's visible.

Good question, this is the gap a self-hoster hits first.