Skip to main content
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.