Overview
Private repository access requires authentication tokens that prove your authorization to access the repository content. DeepWiki supports multiple platforms and token types with different permission models.GitHub
Classic and fine-grained personal access tokens with repository scope
GitLab
Personal access tokens with read_repository scope
BitBucket
App passwords with repository read permissions
Enterprise
Organization and enterprise-specific considerations
GitHub Access Tokens
GitHub offers two types of personal access tokens with different scopes and capabilities.Classic Personal Access Tokens
Navigate to Token Settings
- Go to GitHub.com and sign in
- Click your profile picture → Settings
- In the left sidebar, click Developer settings
- Click Personal access tokens → Tokens (classic)
Classic tokens provide broad access but are easier to set up for multiple repositories.
Generate New Token
- Click Generate new token → Generate new token (classic)
- Enter a descriptive note (e.g., “DeepWiki Documentation Access”)
- Set expiration (recommended: 90 days for security)
- Select scopes based on your needs:
Private Repository Access
Private Repository Access
Required scope:
repo- Full control of private repositories
- Includes read/write access to code, issues, pull requests
- Use when: Accessing private repositories you own or have been granted access to
Public Repository Only
Public Repository Only
Required scope:
public_repo- Access to public repositories only
- More limited permissions
- Use when: Only accessing public repositories (DeepWiki works without tokens for public repos)
Organization Repositories
Organization Repositories
Additional scope:
read:org- Read organization membership
- Required for some organization private repositories
- Use when: Accessing private repositories owned by organizations
Fine-Grained Personal Access Tokens (Beta)
For more granular control over repository access:Create Fine-Grained Token
- In Developer settings → Personal access tokens
- Click Fine-grained tokens → Generate new token
- Configure token details:
- Token name: Descriptive name
- Expiration: 90 days recommended
- Resource owner: Select your account or organization
Select Repository Access
Choose repository access level:
- Selected repositories
- All repositories
Best for: Specific repositories
- Click “Selected repositories”
- Choose specific repositories from dropdown
- More secure, limited scope
- Repository permissions: Contents (Read)
- Metadata: Read
GitHub Enterprise
For GitHub Enterprise Server instances:Enterprise Server Setup
Enterprise Server Setup
Token creation process:
- Navigate to your GitHub Enterprise instance
- Follow same steps as GitHub.com
- Ensure your DeepWiki instance can reach enterprise server
- Network connectivity requirements
- Certificate trust for self-signed certificates
- Custom API endpoints configuration
SAML and SSO
SAML and SSO
With SAML SSO enabled:
- Create personal access token normally
- Authorize token for SSO:
- Go to token settings
- Click “Configure SSO” next to your organization
- Click “Authorize”
- Organization policies may restrict token creation
- Admin approval may be required
- Token expiration policies may be enforced
GitLab Access Tokens
GitLab uses personal access tokens with specific scope-based permissions.Personal Access Token Creation
Access Token Settings
- Sign in to GitLab.com or your GitLab instance
- Click your avatar → Edit profile
- In the left sidebar, click Access Tokens
GitLab tokens are more granular than GitHub classic tokens, allowing precise permission control.
Create New Token
- Click Add new token
- Configure token settings:
- Token name: Descriptive name (e.g., “DeepWiki Access”)
- Expiration date: Set appropriate expiration
- Select scopes: Choose required permissions
Repository Access Scopes
Repository Access Scopes
For private repository access:
- ✅
read_repository- Clone and pull from repositories - ⚠️
read_user- Read user information (optional) - ⚠️
read_api- Read API access (if using API features)
- ❌
write_repository- Not needed for documentation - ❌
api- Full API access (too broad)
Group and Project Access
Group and Project Access
For group projects:
- Add
read_repositoryscope - Ensure you’re a group member
- Check group access policies
- Token automatically inherits project access
- No additional configuration needed
- Respects project visibility settings
GitLab Self-Managed
For self-hosted GitLab instances:- Standard Instance
- Admin Considerations
Configuration requirements:
- Same token creation process
- Verify network connectivity to your GitLab instance
- Check SSL certificate configuration
BitBucket Access
BitBucket uses app passwords instead of traditional tokens, with different permission models.App Password Creation
Access App Password Settings
- Sign in to BitBucket.org
- Click your avatar → Personal BitBucket settings
- In the left menu, click App passwords
BitBucket app passwords are repository-specific credentials with granular permissions.
Create App Password
- Click Create app password
- Configure password settings:
- Label: Descriptive name (e.g., “DeepWiki Documentation”)
- Permissions: Select required access levels
Repository Permissions
Repository Permissions
Required permissions:
- ✅ Repositories: Read - Access repository content
- ✅ Pull requests: Read - Access PR information (optional)
- ⚠️ Issues: Read - Access issues (optional)
- ❌ Repositories: Write - Not needed for documentation
- ❌ Repositories: Admin - Administrative access
- ❌ Account - Account-level access
Access Scope
Access Scope
Team repositories:
- Ensure you have repository access
- App password inherits team permissions
- Verify with team administrators
- Full access to your own repositories
- No additional configuration needed
BitBucket Server/Data Center
For on-premises BitBucket instances:- Personal Access Tokens
- HTTP Basic Authentication
BitBucket Server uses personal access tokens:
- Go to your BitBucket Server instance
- Click your avatar → Manage account
- Click Personal access tokens
- Create token with Repository read permission
Token Security Best Practices
Secure Token Storage
Development Environment
Development Environment
Local development:Configuration management:
Production Environment
Production Environment
Container secrets:Kubernetes secrets:
Token Rotation
Token Rotation
Automated rotation strategy:
- Generate new tokens before current ones expire
- Test new tokens in staging environment
- Update production with new tokens
- Revoke old tokens after successful deployment
- Monitor for failures and rollback if needed
- High-security environments: 30-60 days
- Standard environments: 90 days
- Development environments: 180 days
Access Control
Principle of Least Privilege
Minimize token permissions:
- Use read-only scopes when possible
- Avoid admin or write permissions
- Prefer fine-grained tokens over classic tokens
- Regular audit of token permissions
Review token permissions quarterly to ensure they match current needs.
Using Tokens with DeepWiki
API Integration
- HTTP API
- Python SDK
- JavaScript SDK
Direct API calls:
Web Interface Integration
Organization and Enterprise Considerations
GitHub Organizations
Organization Policies
Organization Policies
Common organizational restrictions:
- Personal access token policies
- Required two-factor authentication
- IP allowlists for API access
- Audit logging requirements
- Check organization settings before creating tokens
- Request necessary permissions from administrators
- Use fine-grained tokens when possible for better compliance
- Document token usage for audit purposes
Enterprise Security
Enterprise Security
Enterprise GitHub features:
- Advanced security features
- Custom SAML/OIDC integration
- Advanced audit logging
- Custom policies and restrictions
- Shorter token lifetimes
- Required approval workflows
- Enhanced monitoring requirements
- Integration with enterprise identity systems
- Coordinate with security teams on token policies
- Use service accounts for automated access
- Implement token rotation procedures
- Monitor token usage closely
GitLab Groups and Projects
- Group-Level Access
- Project Permissions
GitLab group considerations:
- Group membership requirements
- Project-level permissions inheritance
- Shared runner restrictions
- Group-level tokens (GitLab Premium+)
Token Management at Scale
Multi-Repository Management
Monitoring and Analytics
Usage Analytics
Usage Analytics
Track token performance:
Health Monitoring
Health Monitoring
Token health checks:
Troubleshooting
Common Issues
Authentication Failures
Authentication Failures
Symptom: “Bad credentials” or “Invalid token” errorsDiagnosis checklist:
-
Token format validation:
-
Token expiration check:
-
Permission verification:
- Generate new token with correct permissions
- Verify token hasn’t expired
- Check organization SSO requirements
- Confirm repository access permissions
Permission Issues
Permission Issues
Symptom: “Not Found” errors for existing repositoriesCommon causes:
- Token lacks repository scope
- Repository is private but token has public-only permissions
- Organization requires SSO authorization for tokens
- User doesn’t have repository access
-
Verify repository permissions:
-
Update token permissions:
- For GitHub: Add
reposcope for private repositories - For GitLab: Add
read_repositoryscope - For BitBucket: Ensure “Repositories: Read” permission
- For GitHub: Add
-
Handle organization restrictions:
- Authorize token for SSO if required
- Request repository access from administrators
- Use organization-approved tokens
Rate Limiting
Rate Limiting
Symptom: “API rate limit exceeded” errorsUnderstanding rate limits:Best practices:
- GitHub: 5,000 requests/hour for authenticated requests
- GitLab: 2,000 requests/minute for personal tokens
- BitBucket: 1,000 requests/hour for authenticated requests
- Implement exponential backoff
- Cache API responses when possible
- Use webhooks instead of polling
- Monitor rate limit headers