Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.

Prefect Community

Hi I am *still* tying to get the server working robustly on k8s using the helm chart in the repo - my current problem if anyone could help?

I don't want the UI to have to talk to the apollo server via the open internet on the public ip so I have tried to set the following overrides;
```agent:

  # enabled determines if the Prefect Kubernetes agent is deployed
  enabled: true
  prefectLabels: ['prefect-agent']

ui:
  apolloApiUrl: <http://prefect-apollo.prefect:4200/graphql>```
The UI just gives me the following error;

```Oops! It looks like something went wrong when trying to connect; make sure Prefect Server is running at the URL above and try again.```
However if I start a shell on the UI pod and run curl against that URL it connects as expected to the api;

```# curl <http://prefect-apollo.prefect:4200/graphql>
GET query missing.# ```
The reason I am even trying this is because if I use the public IP of the apollo server I always end up getting very slow UI and occasionally complete disconnects from the graphql server.

Apollo is the API of Prefect which is queried from the frontend (browser), the service must be publicly available in order for the UI to talk with the backend.

Yeah but the frontend is running on the same kubernetes cluster

So why wont it communicate via the cluster network?

Is what you are saying that all the communication is happening in my browser? rather than the browser sending requests to its backend which forwards within the cluster to the Apollo api?

Yes, the connection to apollo is from your browser, not from the prefect UI itself.

Ok cool all clear - I wonder if someone could explain the why behind that? Seems like the UI should proxy the requests to the API route no?

I can't speak for the team, but my suspicion is that it's because they designed it with the docker-compose setup in mind, where if you're connecting to apollo to register the flows etc, you would have direct access to it anyway.

But for me (using ECS services) it makes securing apollo from internal rogue users more difficult.

It was designed to contact our API originally which is always available and the UI web server isn’t currently capable of proxying requests so there would be some pretty significant changes.