Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt

Use this file to discover all available pages before exploring further.

This guide explains the network connectivity options for Bytebase features that require external access, including GitOps workflows, SSO authentication, and webhooks.

​
Features Requiring External Access

  • GitOps Workflows: CI/CD platforms (GitHub Actions, GitLab CI, etc.) need to call Bytebase API
  • SSO Authentication: OAuth2/OIDC/SAML providers need callback access
  • Webhooks: External services sending events to Bytebase

​
Three Network Patterns

​
1. Bytebase Cloud

Use Bytebase Cloud for instant setup without infrastructure management. External services connect directly. Best for: Quick testing, evaluation, and small teams

​
2. Self-Hosted Bytebase (Production)

Keep Bytebase inside your private network for security. With cloud CI/CD (GitHub.com, GitLab.com, Bitbucket, Azure DevOps):
  • Works without self-hosted runners
  • Cloud CI/CD can call Bytebase directly (or via the required exposed endpoint)
With self-hosted CI/CD (GitHub Enterprise Server, self-hosted GitLab, Jenkins):
  • Install self-hosted runners/agents inside your network
  • Runners connect to your internal Bytebase without exposing it to the internet
Best for: Production setups with strict network boundaries.

​
3. Self-Hosted Local Testing with Reverse Proxy

Temporarily expose local Bytebase for testing using reverse proxy tools such as:
Never use reverse proxy tools in production. They are for local testing only.
Important for Self-Hosted: Remember to configure the External URL in Bytebase Settings > General with your public URL for SSO callbacks and other integrations to work properly.