Self-hosted connectivity

Use Self-hosted connectivity to resolve base URL, allowlist, firewall, tunnel, private-network and TLS blocks without requesting private credentials.

Developers, infrastructure admins and agencies

Feature availability

Product, package, provider and deployment boundaries for this page.

Available from
Current documentation
Providers
jiragithubgitlabbitbucketyoutrackazure-devopswebhook
Deployment modes
self-hosted

Before retrying self-hosted access

Use this page when a self-hosted provider, webhook target, repository, issue tracker or private-network-constrained integration cannot be reached. Start from the saved target because it owns the base URL, deployment mode, network policy, allowlist, tunnel and TLS state.

  • Verify the base URL
  • Check `base_url`, `allowlist`, `allowlist_status`, `tunnel_url` and `tls_status`.
  • Keep VPN credentials, private admin passwords and ad hoc private access out of troubleshooting.

Triage the network path

Follow the path `Settings → Self-hosted target → Network check → Allowlist, tunnel, fallback or stop`.

  1. Open `/settings` and choose the self-hosted provider or webhook target. Result: `provider_key`, `deployment_mode`, `base_url` and `private_network_policy` are visible before retry.
  2. Read `connectivity_check_id`, `last_checked_at`, `dns_status`, `tls_status`, `firewall_status`, `allowlist_status`, `tunnel_status` and `tunnel_url`. Result: the page separates DNS, TLS, firewall, allowlist and tunnel blockers.
  3. If `SELF_HOSTED_BASE_URL_UNSAFE` appears, confirm the `base_url` belongs to the customer and uses an approved scheme/host. Result: unsafe private or unrelated targets stay blocked.
  4. If `SELF_HOSTED_DNS_FAILED` appears, fix public DNS or the approved private resolver path before retry. Result: WebRiskOps does not guess a private address.
  5. If `SELF_HOSTED_TLS_INVALID` appears, repair the certificate chain and hostname match before provider or webhook calls. Result: signed delivery and provider auth do not use unsafe TLS.
  6. If `SELF_HOSTED_ALLOWLIST_MISSING` or `SELF_HOSTED_FIREWALL_BLOCKED` appears, add the documented `egress_ip` to the `allowlist`. Result: access is explicit and customer-owned.
  7. If `SELF_HOSTED_TUNNEL_UNREACHABLE` appears, verify the approved tunnel health and `tunnel_url`. Result: private-network access is retried only through the configured tunnel.
  8. Return to `/reports/{report}/ticket-exports`, `/fix-tasks/{fixTask}` or provider setup only after connectivity is ready. Result: delivery, PR creation or provider sync retries use a known-safe network path.
  9. Use portable export or ticket-only fallback when `SELF_HOSTED_PRIVATE_NETWORK_REJECTED` applies. Result: WebRiskOps does not request VPN credentials, admin passwords or ad hoc private access.
  10. Continue to Cloud and self-hosted integrations, Cloud and self-hosted distinctions, Provider connection errors or Portable export fallbacks based on the owner that remains. Result: the next guide owns setup, platform access or fallback.

Self-hosted connectivity reasons

Use the reason code before retrying a provider, webhook, repository or export action.

  • `SELF_HOSTED_CONNECTIVITY_BLOCKED` means the target cannot be reached safely from the configured WebRiskOps environment.
  • `SELF_HOSTED_BASE_URL_UNSAFE` means the target URL, scheme, host or private-network policy is not approved.
  • `SELF_HOSTED_DNS_FAILED` means name resolution failed through the approved public or private path.
  • `SELF_HOSTED_TLS_INVALID` means certificate trust, hostname match or TLS configuration blocks access.
  • `SELF_HOSTED_ALLOWLIST_MISSING`, `SELF_HOSTED_FIREWALL_BLOCKED` and `SELF_HOSTED_TUNNEL_UNREACHABLE` identify the network control that still owns the block.

Allowlist tunnel or fallback rules

Connectivity must be explicit and customer-owned.

  • Add only the documented WebRiskOps `egress_ip` or approved address range to the customer `allowlist`.
  • Use a tunnel only when `private_network_policy` allows it and `tunnel_status` is healthy.
  • Retry provider calls, webhook delivery or PR creation only after the connectivity check is current.
  • Use portable export, ticket-only fallback or customer-applied evidence when private-network access is intentionally unavailable.

Ready and blocked self-hosted states

A self-hosted target is ready when network, TLS and ownership checks all agree.

  • Ready: base URL is owned, deployment mode is self-hosted, DNS resolves, TLS is valid, firewall and allowlist allow WebRiskOps egress, tunnel is healthy when used and `last_checked_at` is current.
  • Still blocked: unsafe base URL, DNS failure, invalid TLS, firewall block, missing allowlist, unreachable tunnel, rejected private-network policy or stale connectivity check.
  • Stop: the customer will not authorize a network path, endpoint ownership is unclear or access would require VPN credentials, admin passwords or unapproved private infrastructure access.

Continue after connectivity triage

Use the linked guide for the owner that remains.

  • Cloud and self-hosted integrations explains provider deployment mode, auth method, base URL and allowlist setup.
  • Cloud and self-hosted distinctions explains platform access boundaries before requesting connected access.
  • Provider connection errors explains auth, scope, base URL and provider retry states after network access is ready.
  • Portable export fallbacks and Safe fallback paths explain what to use when self-hosted access is intentionally unavailable.

Related documentation

Was this page helpful?

Feedback goes into the product documentation review queue.