GitNexus

Why deploy GitNexus Render on Render?

GitNexus is a self-hosted code-intelligence tool that parses a repository into a knowledge graph of symbols and their relationships, accessible through a web UI. It lets developers browse call and inheritance graphs, search execution flows, and run impact analysis to determine what breaks when a piece of code changes. The core service requires no API keys and operates entirely on the code graph.

Deploy GitNexus and Render's Blueprint stands up both services—the public gitnexus-web reverse proxy and the private gitnexus-data indexing worker—already wired together over Render's private network, so /api/* calls route internally without you exposing the backend or hand-configuring service discovery. The persistent disk at /data/gitnexus for your code graph, repo clones, and registry is pre-provisioned, and the worker's memory ceiling (GITNEXUS_SERVER_WORKER_MAX_OLD_SPACE_MB) plus optional Azure DevOps credentials are surfaced as prompted env vars at deploy time instead of buried in Docker configs you'd otherwise write yourself. You skip the Dockerfile plumbing, reverse-proxy setup, and disk-mounting that a DIY deploy demands—one click gives you a same-origin, backend-isolated architecture where only the web UI is internet-reachable.

Architecture

What you can build

After you click Deploy, you'll have a hosted code-intelligence service running at a public URL where you can point GitNexus at any repository and index it into a queryable knowledge graph. From the browser, you can navigate call and inheritance graphs, search for execution flows by concept, and run impact analysis to see what a change would break before you make it. The core loop works without any API keys, with repository state persisted on disk so your index survives between sessions.

Key features

• Two-service split architecture: Deploys a public web UI service and an internal-only private API server, so the indexing backend is never exposed to the internet.
• Same-origin reverse proxy: The web service proxies all /api/* calls to the private server, eliminating CORS configuration and public API exposure.
• No API key required: The core index-graph-query-impact workflow runs entirely on the code graph without any external API keys or credentials.
• Persistent disk state: The server stores its index, cloned repos, and registry on a persistent disk at /data/gitnexus, running as a single instance to keep state consistent.
• Configurable indexer memory: Indexing RAM can be scaled via the gitnexus-server plan and tuned with GITNEXUS_SERVER_WORKER_MAX_OLD_SPACE_MB to avoid OOM kills on large repos.

Use cases

• New engineer maps unfamiliar codebase by browsing call and inheritance graphs
• Developer runs impact analysis before refactoring to check blast radius
• Tech lead hosts session-isolated demo for onboarding or interview candidates
• Team indexes private Azure DevOps repo to trace authentication execution flows

What's included

Prerequisites

• Azure DevOps Server URL: The base URL of your Azure DevOps Server instance that GitNexus will index repositories from.
• Azure DevOps Personal Access Token: A personal access token authorizing GitNexus to clone and index repositories from your Azure DevOps Server instance.

Next steps

1. Open the gitnexus-web service URL and index a public GitHub repo (e.g. paste its URL and start indexing) — The job runs to completion and the knowledge graph populates within a minute or two for a small repo, with no out-of-memory error on gitnexus-server
2. Click a symbol in the graph and then run a concept query like "authentication" — You should see the symbol's callers and callees, and the query should return the matching execution flow through the code graph
3. Open impact analysis on an indexed symbol — You should see its blast radius, listing the direct callers and affected flows that would break if you changed it

Resources

• GitNexus official site