From 053525b7fc8b16c718851969999f327ecebabf37 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 16:50:48 +0100 Subject: [PATCH 1/6] docs: add egress filtering guide with Squid proxy --- docs/docs.json | 3 +- .../egress-filtering-squid-proxy.mdx | 277 ++++++++++++++++++ 2 files changed, 279 insertions(+), 1 deletion(-) create mode 100644 docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx diff --git a/docs/docs.json b/docs/docs.json index 9d762f2..18fccf8 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -153,7 +153,8 @@ "pages": [ "getting-started/guides/advanced-tutorials/cloudflare-custom-domain", "getting-started/guides/advanced-tutorials/rate-limiting", - "getting-started/guides/advanced-tutorials/ip-header-authorization" + "getting-started/guides/advanced-tutorials/ip-header-authorization", + "getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy" ] }, { diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx new file mode 100644 index 0000000..31c4854 --- /dev/null +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -0,0 +1,277 @@ +--- +title: "Filter Outbound Traffic with an Egress Proxy" +description: "Restrict outbound HTTP(S) traffic for a single application using a Squid forward proxy and Kubernetes NetworkPolicy" +--- + +This guide shows how to restrict outbound HTTP(S) traffic for a single application running on a Qovery-managed cluster. The pattern is particularly useful for **agentic or automation workloads** where you want to reduce data exfiltration risk by only allowing calls to a predefined set of domains. + + +Qovery's built-in controls focus on ingress. Per-application egress domain filtering is handled at the Kubernetes level using a dedicated forward proxy. + + +## How it works + +The approach has three parts: + +1. **Squid forward proxy** — runs inside the cluster and enforces a domain allowlist +2. **App environment variables** — tell your application to route all outbound traffic through the proxy +3. **Kubernetes NetworkPolicy** *(optional)* — prevents the application from bypassing the proxy by talking directly to the internet + +``` +[ Your App ] → [ Squid Proxy ] → [ Allowed domains only ] + ↑ + allowlist enforced here +``` + + +IP-based filtering (Security Groups / NACLs) is **not reliable** for this use case. Services like GitHub, npm, Anthropic, and Linear sit behind CDNs and use multiple IPs that change over time. Domain-based filtering via a forward proxy is the right approach. + + +## Prerequisites + +- A Qovery environment with at least one application running +- Basic familiarity with Kubernetes and Helm +- A list of domains your application needs to reach + + +**About EKS Application Network Policies and Envoy:** EKS FQDN-based policies are tied to EKS Auto Mode and are not available on standard Qovery-managed clusters. The Envoy Gateway being introduced in Qovery covers ingress only — it is a different component from an egress gateway. The proxy pattern described here is the recommended approach today. + + +## Step 1: Deploy a Squid proxy in your environment + +Deploy Squid as a dedicated service inside the same Qovery environment as your application. You can use a Helm chart or a custom container. + +### Squid configuration + +Create a `squid.conf` with your domain allowlist: + +```nginx +http_port 3128 + +# Define your approved destinations +acl allowed_domains dstdomain \ + .anthropic.com \ + .github.com \ + .githubusercontent.com \ + .npmjs.org \ + .npmjs.com \ + .linear.app + +http_access allow allowed_domains +http_access deny all + +# Send logs to stdout/stderr for visibility in Qovery logs +access_log stdio:/dev/stdout +cache_log stdio:/dev/stderr +``` + + +Start with a permissive allowlist and use the proxy logs to discover all the domains your application actually contacts before tightening it. SaaS services often use multiple hostnames for APIs, CDNs, redirects, and object storage. + + +### Deploy via Helm + +Use any Squid Helm chart and mount the config above. Example `values.yaml`: + +```yaml +replicaCount: 1 + +service: + type: ClusterIP + port: 3128 + +resources: + requests: + cpu: 100m + memory: 128Mi + limits: + cpu: 500m + memory: 512Mi + +config: | + http_port 3128 + + acl allowed_domains dstdomain \ + .anthropic.com \ + .github.com \ + .githubusercontent.com \ + .npmjs.org \ + .npmjs.com \ + .linear.app + + http_access allow allowed_domains + http_access deny all + + access_log stdio:/dev/stdout + cache_log stdio:/dev/stderr +``` + + +Use `ClusterIP` — this proxy is for internal use only and should never be exposed publicly. + + +## Step 2: Configure the application to use the proxy + +Add the following environment variables to your application in Qovery: + +| Variable | Value | Purpose | +|---|---|---| +| `HTTPS_PROXY` | `http://squid-proxy:3128` | Route HTTPS traffic through proxy | +| `HTTP_PROXY` | `http://squid-proxy:3128` | Route HTTP traffic through proxy | +| `NO_PROXY` | `127.0.0.1,localhost,.svc,.cluster.local` | Bypass proxy for internal traffic | + +Replace `squid-proxy` with the actual Kubernetes service name of your Squid deployment. + + +Some runtimes and libraries also read lowercase variants: `http_proxy`, `https_proxy`, `no_proxy`. Set both if your language runtime requires it. + + + +Always include `.svc` and `.cluster.local` in `NO_PROXY`. Without this, internal Kubernetes service calls will be routed through the proxy and may fail. + + +## Step 3: Validate the setup + +Once both services are deployed, exec into your application container and test: + +```bash +# Should succeed — domain is in the allowlist +curl -I https://api.anthropic.com + +# Should succeed +curl -I https://api.github.com + +# Should fail — domain is not in the allowlist +curl -I https://example.org +``` + +Check the Squid container logs in Qovery to see all outbound requests and their status. + +## Step 4 (optional): Enforce with a NetworkPolicy + +A NetworkPolicy prevents your application from bypassing the proxy and talking directly to the internet. This step requires that your cluster networking plugin supports egress enforcement (e.g. AWS VPC CNI with network policy support enabled, or Calico/Cilium). + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: my-agent-egress-via-proxy +spec: + podSelector: + matchLabels: + app: my-agent # label on your application pods + policyTypes: + - Egress + egress: + # Allow traffic to the Squid proxy + - to: + - podSelector: + matchLabels: + app: squid-proxy # label on your Squid pods + ports: + - protocol: TCP + port: 3128 + # Allow DNS resolution + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + ports: + - protocol: UDP + port: 53 + - protocol: TCP + port: 53 +``` + + +Once an egress NetworkPolicy is applied, **only traffic explicitly listed is allowed** — everything else is dropped by default. Make sure DNS is allowed or name resolution will fail entirely. + + + +This NetworkPolicy is optional but strongly recommended for workloads where data exfiltration risk is a concern, such as autonomous AI agents. + + +## Domain allowlist reference + +For common SaaS services used in AI agent workloads, here is a starter allowlist. Adjust based on what your proxy logs show during testing. + + + + ``` + .anthropic.com + ``` + + + + ``` + .github.com + .githubusercontent.com + .githubassets.com + ``` + + + + ``` + .npmjs.org + .npmjs.com + ``` + + + + ``` + .linear.app + ``` + + + + +Treat this list as a starting point only. SaaS services frequently use additional hostnames for CDNs, object storage, authentication, and redirects. Always validate with proxy logs before locking down the allowlist. + + +## Troubleshooting + + + + Check that: + - `HTTPS_PROXY` and `HTTP_PROXY` are set and point to the correct hostname and port + - `NO_PROXY` includes `.svc` and `.cluster.local` + - The Squid pod is running and healthy + - The Squid service name matches the hostname in the env vars + - If NetworkPolicy is applied, DNS (port 53) is explicitly allowed + + + + Check: + - Whether the service uses a different hostname than expected (e.g. a CDN endpoint) + - Whether there are HTTP redirects to a non-allowlisted domain + - The proxy access log — it shows the exact destination the client is requesting + + + + Check that `.svc` and `.cluster.local` are in `NO_PROXY`. Without this, Kubernetes internal service discovery goes through the proxy and typically fails. + + + + This often happens when a SaaS service uses multiple backend hostnames or load balances across CDN nodes. Check proxy logs for blocked requests and add the missing hostnames to the allowlist. + + + +## Related documentation + + + + Configure environment variables and secrets on your services + + + + Deploy Squid or other tools as a Helm service in Qovery + + + + Security and compliance capabilities in Qovery + + + + Fine-tune service behavior with advanced settings + + From 95606da50c1d0ea3b3371ddaf80eea5343289b2f Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 16:56:59 +0100 Subject: [PATCH 2/6] docs: make egress filtering guide more generic --- .../egress-filtering-squid-proxy.mdx | 82 +++---------------- 1 file changed, 13 insertions(+), 69 deletions(-) diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx index 31c4854..c024c92 100644 --- a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -3,7 +3,7 @@ title: "Filter Outbound Traffic with an Egress Proxy" description: "Restrict outbound HTTP(S) traffic for a single application using a Squid forward proxy and Kubernetes NetworkPolicy" --- -This guide shows how to restrict outbound HTTP(S) traffic for a single application running on a Qovery-managed cluster. The pattern is particularly useful for **agentic or automation workloads** where you want to reduce data exfiltration risk by only allowing calls to a predefined set of domains. +This guide shows how to restrict outbound HTTP(S) traffic for a single application running on a Qovery-managed cluster. The goal is to enforce a domain allowlist so the application can only reach a predefined set of external services. Qovery's built-in controls focus on ingress. Per-application egress domain filtering is handled at the Kubernetes level using a dedicated forward proxy. @@ -24,7 +24,7 @@ The approach has three parts: ``` -IP-based filtering (Security Groups / NACLs) is **not reliable** for this use case. Services like GitHub, npm, Anthropic, and Linear sit behind CDNs and use multiple IPs that change over time. Domain-based filtering via a forward proxy is the right approach. +IP-based filtering (Security Groups / NACLs) is **not reliable** for domain-based allowlisting. Many external services sit behind CDNs and use multiple IPs that change over time. A forward proxy that filters on the destination hostname is the right approach. ## Prerequisites @@ -33,10 +33,6 @@ IP-based filtering (Security Groups / NACLs) is **not reliable** for this use ca - Basic familiarity with Kubernetes and Helm - A list of domains your application needs to reach - -**About EKS Application Network Policies and Envoy:** EKS FQDN-based policies are tied to EKS Auto Mode and are not available on standard Qovery-managed clusters. The Envoy Gateway being introduced in Qovery covers ingress only — it is a different component from an egress gateway. The proxy pattern described here is the recommended approach today. - - ## Step 1: Deploy a Squid proxy in your environment Deploy Squid as a dedicated service inside the same Qovery environment as your application. You can use a Helm chart or a custom container. @@ -50,12 +46,8 @@ http_port 3128 # Define your approved destinations acl allowed_domains dstdomain \ - .anthropic.com \ - .github.com \ - .githubusercontent.com \ - .npmjs.org \ - .npmjs.com \ - .linear.app + .example.com \ + .another-service.com http_access allow allowed_domains http_access deny all @@ -66,7 +58,7 @@ cache_log stdio:/dev/stderr ``` -Start with a permissive allowlist and use the proxy logs to discover all the domains your application actually contacts before tightening it. SaaS services often use multiple hostnames for APIs, CDNs, redirects, and object storage. +Start with a permissive allowlist and use the proxy logs to discover all the domains your application actually contacts before tightening it. External services often use multiple hostnames for APIs, CDNs, redirects, and object storage. ### Deploy via Helm @@ -92,12 +84,8 @@ config: | http_port 3128 acl allowed_domains dstdomain \ - .anthropic.com \ - .github.com \ - .githubusercontent.com \ - .npmjs.org \ - .npmjs.com \ - .linear.app + .example.com \ + .another-service.com http_access allow allowed_domains http_access deny all @@ -136,30 +124,27 @@ Once both services are deployed, exec into your application container and test: ```bash # Should succeed — domain is in the allowlist -curl -I https://api.anthropic.com - -# Should succeed -curl -I https://api.github.com +curl -I https://allowed-service.example.com # Should fail — domain is not in the allowlist -curl -I https://example.org +curl -I https://not-allowed.example.com ``` Check the Squid container logs in Qovery to see all outbound requests and their status. ## Step 4 (optional): Enforce with a NetworkPolicy -A NetworkPolicy prevents your application from bypassing the proxy and talking directly to the internet. This step requires that your cluster networking plugin supports egress enforcement (e.g. AWS VPC CNI with network policy support enabled, or Calico/Cilium). +A NetworkPolicy prevents your application from bypassing the proxy and talking directly to the internet. This step requires that your cluster networking plugin supports egress enforcement (e.g. AWS VPC CNI with network policy support enabled). ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: - name: my-agent-egress-via-proxy + name: my-app-egress-via-proxy spec: podSelector: matchLabels: - app: my-agent # label on your application pods + app: my-app # label on your application pods policyTypes: - Egress egress: @@ -187,47 +172,6 @@ spec: Once an egress NetworkPolicy is applied, **only traffic explicitly listed is allowed** — everything else is dropped by default. Make sure DNS is allowed or name resolution will fail entirely. - -This NetworkPolicy is optional but strongly recommended for workloads where data exfiltration risk is a concern, such as autonomous AI agents. - - -## Domain allowlist reference - -For common SaaS services used in AI agent workloads, here is a starter allowlist. Adjust based on what your proxy logs show during testing. - - - - ``` - .anthropic.com - ``` - - - - ``` - .github.com - .githubusercontent.com - .githubassets.com - ``` - - - - ``` - .npmjs.org - .npmjs.com - ``` - - - - ``` - .linear.app - ``` - - - - -Treat this list as a starting point only. SaaS services frequently use additional hostnames for CDNs, object storage, authentication, and redirects. Always validate with proxy logs before locking down the allowlist. - - ## Troubleshooting @@ -252,7 +196,7 @@ Treat this list as a starting point only. SaaS services frequently use additiona - This often happens when a SaaS service uses multiple backend hostnames or load balances across CDN nodes. Check proxy logs for blocked requests and add the missing hostnames to the allowlist. + This often happens when an external service uses multiple backend hostnames or load balances across CDN nodes. Check proxy logs for blocked requests and add the missing hostnames to the allowlist. From f253d9daf3f9b96b72846ddbff76bee0be3b583d Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 17:02:13 +0100 Subject: [PATCH 3/6] docs: clarify NetworkPolicy works out of the box on Qovery clusters --- .../guides/advanced-tutorials/egress-filtering-squid-proxy.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx index c024c92..4b684c1 100644 --- a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -134,7 +134,7 @@ Check the Squid container logs in Qovery to see all outbound requests and their ## Step 4 (optional): Enforce with a NetworkPolicy -A NetworkPolicy prevents your application from bypassing the proxy and talking directly to the internet. This step requires that your cluster networking plugin supports egress enforcement (e.g. AWS VPC CNI with network policy support enabled). +A NetworkPolicy prevents your application from bypassing the proxy and talking directly to the internet. Qovery-managed clusters run AWS VPC CNI with network policy support enabled, so this works out of the box. ```yaml apiVersion: networking.k8s.io/v1 From 91e6b6c993fb109cfc9469a8e082b8fc4b1765b8 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 17:52:44 +0100 Subject: [PATCH 4/6] docs: replace Helm approach with ubuntu/squid container service --- .../egress-filtering-squid-proxy.mdx | 87 ++++++++++--------- 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx index 4b684c1..ce43244 100644 --- a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -13,7 +13,7 @@ Qovery's built-in controls focus on ingress. Per-application egress domain filte The approach has three parts: -1. **Squid forward proxy** — runs inside the cluster and enforces a domain allowlist +1. **Squid forward proxy** — runs inside the cluster as a container service and enforces a domain allowlist 2. **App environment variables** — tell your application to route all outbound traffic through the proxy 3. **Kubernetes NetworkPolicy** *(optional)* — prevents the application from bypassing the proxy by talking directly to the internet @@ -30,16 +30,33 @@ IP-based filtering (Security Groups / NACLs) is **not reliable** for domain-base ## Prerequisites - A Qovery environment with at least one application running -- Basic familiarity with Kubernetes and Helm - A list of domains your application needs to reach -## Step 1: Deploy a Squid proxy in your environment +## Step 1: Deploy Squid as a container service -Deploy Squid as a dedicated service inside the same Qovery environment as your application. You can use a Helm chart or a custom container. +Create a new **Container** service in your Qovery environment using the `ubuntu/squid` image. -### Squid configuration +### Configure the service -Create a `squid.conf` with your domain allowlist: +| Setting | Value | +|---|---| +| Image | `ubuntu/squid` | +| Port | `3128` (do not expose publicly) | + +### Pass the Squid configuration as a file variable + +Rather than baking a config into a custom image, pass your `squid.conf` as a **file variable** mounted directly into the container. + +In Qovery, create a new variable with: + +| Field | Value | +|---|---| +| Name | `SQUID_CONF` (or any name) | +| Type | File | +| Mount path | `/etc/squid/squid.conf` | +| Value | *(the squid.conf content below)* | + +File content: ```nginx http_port 3128 @@ -57,45 +74,25 @@ access_log stdio:/dev/stdout cache_log stdio:/dev/stderr ``` +Replace `.example.com` and `.another-service.com` with the domains your application actually needs to reach. + Start with a permissive allowlist and use the proxy logs to discover all the domains your application actually contacts before tightening it. External services often use multiple hostnames for APIs, CDNs, redirects, and object storage. -### Deploy via Helm +### Configure health probes -Use any Squid Helm chart and mount the config above. Example `values.yaml`: - -```yaml -replicaCount: 1 +Add the following exec probe so Qovery (and Kubernetes) can verify Squid is healthy: -service: - type: ClusterIP - port: 3128 +| Probe | Command | +|---|---| +| Liveness | `squid -k check` | +| Readiness | `squid -k check` | -resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 500m - memory: 512Mi - -config: | - http_port 3128 - - acl allowed_domains dstdomain \ - .example.com \ - .another-service.com - - http_access allow allowed_domains - http_access deny all - - access_log stdio:/dev/stdout - cache_log stdio:/dev/stderr -``` +`squid -k check` sends a signal to the running Squid process and exits with a non-zero code if the process is not responding — making it a reliable health signal. -Use `ClusterIP` — this proxy is for internal use only and should never be exposed publicly. +Do not expose this service publicly. It is an internal proxy and should only be reachable from within the cluster. ## Step 2: Configure the application to use the proxy @@ -104,11 +101,11 @@ Add the following environment variables to your application in Qovery: | Variable | Value | Purpose | |---|---|---| -| `HTTPS_PROXY` | `http://squid-proxy:3128` | Route HTTPS traffic through proxy | -| `HTTP_PROXY` | `http://squid-proxy:3128` | Route HTTP traffic through proxy | +| `HTTPS_PROXY` | `http://:3128` | Route HTTPS traffic through proxy | +| `HTTP_PROXY` | `http://:3128` | Route HTTP traffic through proxy | | `NO_PROXY` | `127.0.0.1,localhost,.svc,.cluster.local` | Bypass proxy for internal traffic | -Replace `squid-proxy` with the actual Kubernetes service name of your Squid deployment. +Replace `` with the internal DNS name of the Squid service (the Qovery service name in lowercase, e.g. `squid-proxy`). Some runtimes and libraries also read lowercase variants: `http_proxy`, `https_proxy`, `no_proxy`. Set both if your language runtime requires it. @@ -179,7 +176,7 @@ Once an egress NetworkPolicy is applied, **only traffic explicitly listed is all Check that: - `HTTPS_PROXY` and `HTTP_PROXY` are set and point to the correct hostname and port - `NO_PROXY` includes `.svc` and `.cluster.local` - - The Squid pod is running and healthy + - The Squid pod is running and healthy (`squid -k check` probe passes) - The Squid service name matches the hostname in the env vars - If NetworkPolicy is applied, DNS (port 53) is explicitly allowed @@ -198,17 +195,21 @@ Once an egress NetworkPolicy is applied, **only traffic explicitly listed is all This often happens when an external service uses multiple backend hostnames or load balances across CDN nodes. Check proxy logs for blocked requests and add the missing hostnames to the allowlist. + + + Make sure the container has fully started before the probe runs — `ubuntu/squid` may take a few seconds to initialize. Add a `initialDelaySeconds` to the probe if needed. You can also exec into the container and run `squid -k check` manually to check the process state. + ## Related documentation - Configure environment variables and secrets on your services + Configure environment variables and file variables on your services - - Deploy Squid or other tools as a Helm service in Qovery + + Deploy a container image as a Qovery service From 1c87118afbc1e90b78bb73628d93c86e2da539a4 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 17:54:37 +0100 Subject: [PATCH 5/6] docs: use built-in QOVERY_CONTAINER__HOST_INTERNAL variable for proxy URL --- .../egress-filtering-squid-proxy.mdx | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx index ce43244..e702a59 100644 --- a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -101,11 +101,18 @@ Add the following environment variables to your application in Qovery: | Variable | Value | Purpose | |---|---|---| -| `HTTPS_PROXY` | `http://:3128` | Route HTTPS traffic through proxy | -| `HTTP_PROXY` | `http://:3128` | Route HTTP traffic through proxy | +| `HTTPS_PROXY` | `http://$QOVERY_CONTAINER__HOST_INTERNAL:3128` | Route HTTPS traffic through proxy | +| `HTTP_PROXY` | `http://$QOVERY_CONTAINER__HOST_INTERNAL:3128` | Route HTTP traffic through proxy | | `NO_PROXY` | `127.0.0.1,localhost,.svc,.cluster.local` | Bypass proxy for internal traffic | -Replace `` with the internal DNS name of the Squid service (the Qovery service name in lowercase, e.g. `squid-proxy`). +Qovery automatically exposes a built-in variable for each service's internal hostname. For your Squid container service it will look like `QOVERY_CONTAINER__HOST_INTERNAL`. You can find the exact variable name in the **Environment Variables** tab of your Squid service, under the built-in variables section. + +Use it by reference so the value stays correct across redeployments: + +``` +HTTP_PROXY=http://{{ QOVERY_CONTAINER__HOST_INTERNAL }}:3128 +HTTPS_PROXY=http://{{ QOVERY_CONTAINER__HOST_INTERNAL }}:3128 +``` Some runtimes and libraries also read lowercase variants: `http_proxy`, `https_proxy`, `no_proxy`. Set both if your language runtime requires it. From ecec4bd33be02a24b1bbe194d94e99e3294a1ab5 Mon Sep 17 00:00:00 2001 From: Guillaume Da Silva Date: Tue, 17 Mar 2026 17:55:59 +0100 Subject: [PATCH 6/6] docs: remove explicit log config from squid.conf example --- .../advanced-tutorials/egress-filtering-squid-proxy.mdx | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx index e702a59..7f145a2 100644 --- a/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx +++ b/docs/getting-started/guides/advanced-tutorials/egress-filtering-squid-proxy.mdx @@ -68,10 +68,6 @@ acl allowed_domains dstdomain \ http_access allow allowed_domains http_access deny all - -# Send logs to stdout/stderr for visibility in Qovery logs -access_log stdio:/dev/stdout -cache_log stdio:/dev/stderr ``` Replace `.example.com` and `.another-service.com` with the domains your application actually needs to reach.