# Disable proxy pod?

**URL:** <https://discourse.jupyter.org/t/disable-proxy-pod/9348>\
**Category:** BinderHub\
**Tags:** how-to\
**Created:** [May 27, 2021, 5:58pm UTC](https://discourse.jupyter.org/t/disable-proxy-pod/9348 "2021-05-27T17:58:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mapsacosta](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/mapsacosta/32/4492_2.png) [@mapsacosta](https://discourse.jupyter.org/u/mapsacosta)\
**Post date:** [May 27, 2021, 5:58pm UTC](https://discourse.jupyter.org/t/disable-proxy-pod/9348/1 "2021-05-27T17:58:51Z")

</div>

I have searched all over the place and can’t find a way to completely disable the Proxy pod when deploying binderhub through z2\* Helm charts. I’m handling networking separately and it’s just annoying that the pod gets created whenever we install/update and disrupts our network.

Is there a way to do this programmatically? (Via a config knob on the Chart)?

---

<div class="post-metadata">

**Author:** ![manics](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/manics/32/85_2.png) [@manics](https://discourse.jupyter.org/u/manics)\
**Post date:** [June 2, 2021, 6:08pm UTC](https://discourse.jupyter.org/t/disable-proxy-pod/9348/2 "2021-06-02T18:08:22Z")

</div>

It’s not possible, a similar question was asked recently: [Completely disable Proxy deployment creation by the Helm chart](https://discourse.jupyter.org/t/completely-disable-proxy-deployment-creation-by-the-helm-chart/9373)

Could you explain how it’s disrupting your network?

---

<div class="post-metadata">

**Author:** ![mapsacosta](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/mapsacosta/32/4492_2.png) [@mapsacosta](https://discourse.jupyter.org/u/mapsacosta)\
**Post date:** [June 14, 2021, 5:35pm UTC](https://discourse.jupyter.org/t/disable-proxy-pod/9348/3 "2021-06-14T17:35:16Z")

</div>

Hi @manics,

Sorry for the late reply, I was trying to replicate the scenario to gather the info for you.

First thing that can potentially break things is the fact that `interNamespaceAccessLabels` show up in the hub deployment… As you know, hub will have issues starting up if it can’t immediately bind to an address/connect to an external proxy.

In this case, these two [\*] hardcoded configs on the pre-injected `jupyterhub_config.py` prevent the hub from starting up since… well we’re not using the proxy pod and we need the hub to know this and start the proxy on its own:

[\*]

```auto
#Connect to a proxy running in a different pod. Note that *_SERVICE_*
# environment variables are set by Kubernetes for Services

c.ConfigurableHTTPProxy.api_url = (

f'http://{get_name("proxy-api")}:{get_name_env("proxy-api", "_SERVICE_PORT")}'

)

c.ConfigurableHTTPProxy.should_start = False

```

In addition to setting should\_start to `true` and removing the api-url, the configurable-http-proxy binary didn’t seem to be on the preset image so I had to build my own and install it.

These are the basic observations I was able to make. If this is something of interest to you and other users I can work on a PR to make the proxy an “optional” setting on the chart.

Maria A.