Skip to main content
Every branch node runs the language servers for your workspace. When the editor connects, it gets completions, hover documentation, and diagnostics for each language the workspace contains — without installing a language server, writing an editor config, or running a build first.

​
Zero-setup provisioning

The node scans the workspace for source files and provisions a language server for each language it finds. There is nothing to declare and nothing to install:
  • Servers are acquired automatically. Each language’s server is downloaded through the same machinery the build system uses — package ecosystems, release archives, toolchains — so a clean machine and a freshly cloned branch both work out of the box.
  • Project configuration is generated, not hand-written. Before a server starts, the node generates the project model that server expects (for example, a TypeScript configuration with dependency paths resolved, or a compilation database for C/C++) from what the build system already knows. A cold workspace gets correct configs on the first server start.
  • Languages onboard in real time. Add the first Python file to a TypeScript workspace and the node picks it up and starts a Python language server — no restart required.
  • Idle servers shut down. A server with no recent activity is stopped automatically and restarts on demand, so a large multi-language workspace doesn’t hold every runtime warm forever.

​
Supported languages

A Deno provider also exists as an opt-in alternative for Deno projects; it is never enabled automatically.

​
Making dependencies visible with rbs sync

Language servers can only resolve third-party imports that have been downloaded. If you open a branch whose dependencies haven’t been resolved yet, sync them:
After a sync, autocomplete and type checking cover your external dependencies. Useful flags:
Building a target resolves its dependencies too — rbs sync is just the way to get editor intelligence for code you haven’t built yet.

​
How requests are routed

The editor keeps one connection per language and routes each request by the file you’re working in — a TypeScript file talks to the TypeScript server, a Go file to gopls. Diagnostics are tracked per file, so problems in one language never bleed into another’s panel. On the node, servers are keyed by language and project root. In a monorepo with several apps, each project root gets its own server instance with its own configuration, and everyone connected to the branch node shares those server processes — the node warms up once for the whole team.