Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/webhood-io/webhood/llms.txt

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

Webhood’s network stack uses Kong as a reverse proxy layer that sits in front of both the core UI and the backend API. Kong handles TLS termination, which means you only need to provision a certificate in one place and all services behind it benefit. For outbound traffic, the scanner container supports the standard HTTP_PROXY / HTTPS_PROXY environment variables, making it straightforward to route scan traffic through a corporate or network proxy.
The backend service is attached to the frontend internal Docker network only and is not directly exposed on a host port. All external traffic — including API calls from the UI — reaches it through Kong, which bridges the frontend and rest networks. This means TLS configuration on Kong protects the entire externally visible surface of Webhood.

​
Enabling TLS

Kong mounts your certificate and key files read-only from the host filesystem and uses them to terminate HTTPS connections on WEBHOOD_HTTPS_PORT (default 8443).

​
Steps

1. Obtain a TLS certificate and private key. These can be a CA-signed certificate (recommended for production) or a self-signed certificate for internal use. 2. Add the following variables to your .env file: 
# Absolute paths to the cert and key files on the Docker host
WEBHOOD_TLS_CERT=/etc/ssl/certs/webhood.crt
WEBHOOD_TLS_KEY=/etc/ssl/private/webhood.key

# Optional: change the HTTPS host port (default is 8443)
WEBHOOD_HTTPS_PORT=443
3. Restart the stack so Docker Compose re-reads the environment and Kong picks up the new configuration: 
docker compose down && docker compose up -d
Once running, Webhood will be reachable over HTTPS at https://<your-host>:<WEBHOOD_HTTPS_PORT>.

​
How it works

Docker Compose evaluates the WEBHOOD_TLS_CERT and WEBHOOD_TLS_KEY variables using shell parameter expansion. When both are set, the compose file passes the paths to Kong’s KONG_SSL_CERT and KONG_SSL_CERT_KEY environment variables and mounts the files into the container at well-known paths: 
volumes:
  - ${WEBHOOD_TLS_CERT:-/dev/null}:/usr/local/kong/cert.crt:ro
  - ${WEBHOOD_TLS_KEY:-/dev/null}:/usr/local/kong/key.crt:ro
When neither variable is set, the volumes fall back to /dev/null and TLS is not activated — Kong serves plain HTTP only.
The core service has NODE_TLS_REJECT_UNAUTHORIZED=0 set in its environment. This allows the Next.js frontend to make internal API calls to the backend through Kong even when a self-signed certificate is in use. This setting applies only to internal container-to-container communication and does not affect TLS validation in the browsers of users visiting the Webhood UI.

​
Configuring an HTTP Proxy

If your Webhood deployment runs in an environment where outbound internet access requires a proxy, set the standard proxy environment variables in your .env file. Docker Compose forwards these directly to the scanner container. 
# Route all outbound HTTP traffic from the scanner through a proxy
HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128

# Bypass the proxy for internal Docker service hostnames
NO_PROXY=backend,kong,localhost,127.0.0.1

​
NO_PROXY is important

The scanner communicates with the kong container over the internal rest Docker network to submit results and retrieve its configuration. If you do not exclude internal hostnames from the proxy, those requests will be sent to your proxy server, which will fail to resolve Docker-internal names like kong and backend. Always include at minimum: 
NO_PROXY=backend,kong,localhost,127.0.0.1
Add any other internal hostnames or CIDR ranges your deployment uses.

​
Proxy scope

The proxy variables are forwarded only to the scanner container. The core and backend services do not receive these variables; their outbound traffic (if any) is not affected. 
# Excerpt from docker-compose.yml — scanner service only
environment:
  HTTP_PROXY: ${HTTP_PROXY}
  HTTPS_PROXY: ${HTTPS_PROXY}
  NO_PROXY: ${NO_PROXY}

Build docs developers (and LLMs) love

Get started for freeTalk to us