Code Wiki for Private Repos: How to Document Your Private Codebase with AI

Google CodeWiki generates documentation from public repositories. If your repo is private — meaning it requires authentication to access — CodeWiki cannot index it. There is no workaround, no settings toggle, no premium tier that unlocks it. The tool's architecture is built around public URLs.

But the codebase you actually need documented is almost certainly private. It's the repo with your auth system, your database models, your payment flow, your internal APIs. These are the codebases where documentation debt is most expensive — where a new engineer spends three weeks instead of three days finding their way around, where a senior engineer wastes hours grepping through microservices to find where a function is defined.

This post explains how to get code wiki functionality for private repositories — AI-generated documentation, architecture detection, component breakdowns, and interactive codebase chat — on code that CodeWiki can't touch.

Why CodeWiki doesn't support private repos

CodeWiki's workflow is: paste a public GitHub URL, wait, read the generated docs. There's no OAuth flow, no token exchange, no encrypted storage layer. That's because the tool only reads what's already publicly accessible — no authentication needed.

Private repos require a completely different architecture:

1. Authenticated access. The tool needs an OAuth token or personal access token with repo-read scope to clone the repository. This means a security review for most teams.
2. Encrypted storage. When the tool clones your code, it stores it somewhere. That "somewhere" needs encryption at rest, ideally with per-project keys.
3. AI training policy. Your private source code is proprietary. You need to know — in writing — whether it's being used to train foundation models.
4. Access control. Who can see the generated docs? Who can regenerate them? Who can chat with the codebase?
5. Audit logging. For compliance (SOC 2, GDPR, HIPAA), you need to know who accessed what and when.

CodeWiki doesn't implement any of this because it doesn't need to for public repos. It's not a missing feature — it's an architectural boundary. Building private repo support means building a trust infrastructure that public-repo tools never need.

How private repo documentation works with ShipDocs

ShipDocs was built for private repos from the start. Here's the complete flow — from connection to generated docs to AI chat — for a private repository.

Step 1: Connect your Git provider

1. Sign in to ShipDocs at shipdocs.sh.
2. Click Connect GitHub (or GitLab, or Bitbucket).
3. An OAuth flow opens. You grant repo-read scope to ShipDocs.
4. ShipDocs stores the OAuth token with Better-Auth — the same auth library used by production apps handling millions of sessions. The token is refreshed automatically.

You connect once. After that, your private repos appear in the import picker every time you log in.

Step 2: Import a private repo

1. From the dashboard, click New Project.
2. Select Import from Git.
3. ShipDocs lists your repositories — public and private. Pick the private repo you want documented.
4. Click Import.

ShipDocs clones the repository through the authenticated OAuth connection. The clone happens on the server side — your local machine doesn't need Git installed, and the code never touches your browser.

Step 3: Indexing and doc generation

ShipDocs scans the full file tree and detects architectural components:

• Manifest files — package.json, Cargo.toml, go.mod, pyproject.toml, and others
• Directory structure — separate /backend, /frontend, /workers folders
• Import graphs — which files depend on which
• Configuration files — docker-compose.yml, Terraform, Kubernetes manifests

Then it generates:

1. An Overview document — architecture summary, tech stack, key concepts, how components connect
2. One Markdown doc per detected component — backend API, auth system, database layer, frontend routing, workers, CLI, migrations, webhooks, infrastructure

This takes 2–5 minutes for a typical monorepo. The docs are structured, not linear. You click through a sidebar that mirrors your architecture instead of scrolling through one massive page.

Step 4: Encrypted storage

Every source file and generated doc is encrypted with AES-256-GCM before it touches the database. Each project gets a unique data-encryption key. The project keys are wrapped by a master key stored in a KMS-backed hardware vault.

The database holds ciphertext. Plaintext is decrypted on read, per request, with keys that never leave the vault. This is the same encryption model used by GitHub, Vercel, and Linear.

Step 5: AI chat grounded in your docs

After docs are generated, you can ask the AI chat anything about your codebase:

• "Where do we validate webhook signatures?"
• "How does the auth flow work from login to session?"
• "What's the database schema for the billing table?"
• "Which worker handles the retry queue?"

Every answer is grounded in the structured docs generated from your actual source. The model is constrained to the documented surface — it doesn't invent APIs that don't exist. If the answer isn't in the docs, the chat says "I don't see that in the generated documentation" instead of hallucinating.

Every response includes citation tags that link directly to the source file:

Workers pull from the indexQueue (Redis stream). Retries use exponential backoff with a cap of 5 attempts before moving to the dead-letter stream indexDlq.

Sources: workers/src/runner.ts:48 · workers/src/queue.ts:14

This is the code wiki experience developers want — but for private repos, with citations you can verify.

Step 6: Edit, regenerate, and keep docs current

Generated docs aren't frozen. You can:

• Edit any doc in a WYSIWYG Markdown editor. Your edits persist across regenerations.
• Regenerate docs when the code changes. Click Regenerate, and ShipDocs re-scans the latest source and updates the docs.
• Import a different branch to see docs for a feature branch or release tag.

In v2, ShipDocs adds scheduled auto-regeneration and webhook-based re-indexing on push. Your docs will never be more than a commit behind.

The CLI: code wiki from your terminal

Not everyone wants to open a browser. ShipDocs has a CLI built with Ink (a React-based TUI library):

# Install
curl -fsSL shipdocs.sh | sh

# Authenticate (opens browser for OAuth)
shipdocs login

# Upload your current working directory
shipdocs upload

The CLI pushes your local codebase to ShipDocs, triggers doc generation, and returns a URL to the generated docs. It's the fastest path from "I have code" to "I have documentation."

For developers who live in the terminal, this is the code wiki workflow CodeWiki doesn't offer — even for public repos.

Security deep dive: what happens to your private code

This is the question every team asks. Here's the full answer.

OAuth scope

ShipDocs requests repo-read scope only. It cannot write to your repositories, create issues, or modify any content. You can revoke the OAuth token at any time from your Git provider's app settings.

Encryption

• All source files and docs are encrypted with AES-256-GCM before storage
• Each project has a unique data-encryption key (DEK)
• DEKs are wrapped by a master key in a KMS-backed vault
• The database stores only ciphertext
• Plaintext is decrypted per-request; keys never leave the vault

AI training policy

ShipDocs does not train AI models on customer data. We use OpenRouter to route prompts to zero-retention endpoints on OpenAI, Anthropic, and other providers. We pay the providers directly. Your prompts and completions are not retained by them and are not used for training.

Data retention and purge

Deleted projects enter a soft-delete state. After 90 days, a background cron job (running at startup and daily) hard-deletes all associated rows. There is no recovery after purge.

Audit logging

Admin access to decrypted project data is logged with timestamp, administrator identity, and reason. You can request audit logs for your account.

Comparing the private repo experience

CodeWiki is the better tool if you want a quick summary of a public open-source library with zero setup. ShipDocs is the only tool if you need documentation for a private codebase — which is the case for virtually every professional engineering team.

Real-world scenarios: when private repo docs matter most

Onboarding a new engineer

Without docs: 2–3 weeks of pairing, shadowing, and asking questions. The new engineer reads source files one at a time and builds a mental model slowly.

With ShipDocs: 2–3 days. The new engineer reads the Overview, browses the per-component docs, and asks the AI chat specific questions. They find the auth middleware, the database schema, and the queue retry logic in minutes instead of hours.

Code review

Without docs: reviewers open four files, read 200 lines of implementation to understand the pattern, and ask the author for context.

With ShipDocs: reviewers look up the architecture and conventions in the generated docs. The AI chat answers "what's the intended pattern here?" with a cited answer.

Refactoring

Without docs: you grep for usages, hope you found them all, and make the change. Breakage is discovered in staging or production.

With ShipDocs: you ask the AI chat "who calls this function?" and get a real answer grounded in the source. You can verify the answer against the cited file paths.

Compliance audit

Without docs: the auditor asks for architecture documentation. You have a 6-month-old Confluence page and a README. The auditor writes a finding.

With ShipDocs: you share the generated docs or the public showcase link. The architecture, components, and key files are documented and current.

Getting started

1. Sign up at shipdocs.sh — no credit card required.
2. Connect GitHub or GitLab.
3. Pick a private repo and click Import.
4. Read the generated docs and try the AI chat.

The free tier includes 2 private repos, full documentation generation, and 100 chat messages per month. Paid plans start at $29/mo.

Try ShipDocs on your private repo: shipdocs.sh — free tier, no credit card. Get started →