Self-hosted 1.9.0 — canonical way for functions to call the API on the same host?

Setup: Go functions on self-hosted 1.9.0. Public domain via traefik, valid LE cert. APPWRITE_ENDPOINT=https://my.example.com/v1 (auto-injected APPWRITE_FUNCTION_API_ENDPOINT resolves to the same public value).

Problem: functions that fan out 5–6 parallel ListDocuments via errgroup hit 15 s OpenRuntimes gateway timeouts under burst. 4 calls finish in 10–60 ms, 1–2 hang. Error on the hung ones:

Get "https://my.example.com/v1/tablesdb/.../rows":
context deadline exceeded
(Client.Timeout exceeded while awaiting headers)
Sequential single calls always succeed in tens of ms — so it's the public-hostname HTTP path under burst, not MariaDB.

Probe from inside the runtime container:

appwrite (container name) → DNS 10.0.0.26, TCP ok, but GET /v1/health returns the Console HTML SPA, not JSON
appwrite-traefik, traefik → DNS fails (different network)
public hostname → JSON, but throttles under burst (hairpin)
Q: What's the supported way for a function to call /v1/* on the same host without hairpinning out via the public domain?

Is there an internal endpoint that serves /v1/* as JSON regardless of Host header?
Or should I set APPWRITE_ENDPOINT=http://appwrite/v1 and override the SDK's Host header to _APP_DOMAIN? Any helper for that?
Or attach runtimes to a network where appwrite-traefik is reachable, so I can use http://appwrite-traefik/v1?
Or is the official guidance to avoid burst-parallel SDK calls inside a single function execution?
I have full step traces + durations confirming it's the HTTP callback path, not the queries. Thanks 🙏

Answering my own thread — what works on self-hosted 1.9.0.

_APP_FUNCTION_API_ENDPOINT auto-injects the public hostname, so functions hairpin out through Traefik/Cloudflare and stall under parallel load (5–6 SDK calls). _APP_OPTIONS_ROUTER_PROTECTION=disabled does not help on 1.9.0 — the env-gate around that check landed later. The clean fix is to call the appwrite container directly over the internal Docker network, while making router-protection accept that hostname:

docker-compose.yml — appwrite service

networks:
appwrite:
aliases: [appwrite.local]
environment:

• _APP_MIGRATION_HOST # required — Compose only forwards listed vars

.env

_APP_MIGRATION_HOST=appwrite.local
Then docker compose up -d appwrite --force-recreate and verify with docker exec appwrite env | grep MIGRATION_HOST.

On each function: set APPWRITE_ENDPOINT=http://appwrite.local/v1 and redeploy (env changes take effect on a fresh container only).

Two gotchas: (1) listing the var in environment: is mandatory — putting it in .env alone is silently ignored. (2) Updating a variable marked secret is a silent no-op on 1.9.0; delete and recreate.

Result: parallel fan-out drops from a 15s OpenRuntimes timeout to ~90ms.

@AlimFreight🇺🇦 🇨🇦 , sorry for the stupid question but what is wrong with APPWRITE_ENDPOINT=http://localhost/v1 ?

The core issue here is that http://localhost/v1 only works when you are running both your website front-end and Appwrite on the exact same machine during development. Once your site is deployed to production, everything breaks for a few key reasons:

First, localhost always points to the device of the person viewing the site. When a user—say, someone over in Calgary—loads your live website, their web browser is going to try to connect to http://localhost/v1 on their own computer. Because they obviously don't have Appwrite running locally on their machine, every single one of those requests will immediately fail.

Second, you will hit security blocks. Production websites are almost always served over secure https:// connections. If a secure page tries to make an insecure request to an unencrypted http:// address, browsers will completely block it to protect the user. This is known as a "mixed content" error. So, even if localhost somehow managed to resolve to your server, the browser wouldn't let the traffic pass anyway.

Finally, this completely breaks Appwrite Realtime. Those WebSocket subscriptions (client.subscribe()) that you set up to replace your old polling system will fail to connect for those exact same two reasons. Because the connection can't be established, your live indicators will never light up or update.

I asked b/c you said above that your setup (mine as well) is - a self-hosted Appwrite with functions that need to call the API on the same host. Even if the Appwrite server is deployed on production, I am assuming that you will still be able to call another function at localhost. I was not referring to a website but rather to an Appwrite function that calls the Appwrite API.

I mean, there is no browser involved in this context, I don't know why did you bring the browser topic above... but maybe I did not understand your setup

Functions don't run on the host's network — they run in their own Docker containers, each with its own loopback. From inside a function, localhost is the function container itself, where nothing's listening on port 80. To reach the Appwrite API container we have to go via the Docker bridge network.

Plus the issue isn't a browser CORS check — Appwrite has server-side router-protection in PHP that rejects any inbound request whose Host header isn't in $platform['hostnames'] (built from _APP_DOMAIN, _APP_CONSOLE_DOMAIN, _APP_MIGRATION_HOST). That applies to function-to-API calls just as much as to browser calls. _APP_OPTIONS_ROUTER_PROTECTION=disabled is supposed to switch it off but doesn't in 1.9.0.

The combo that finally works: Docker network alias appwrite.local on the appwrite service + _APP_MIGRATION_HOST=appwrite.local in .env (which Appwrite whitelists like localhost) + APPWRITE_ENDPOINT=http://appwrite.local/v1 on each function. Sub-30ms even under burst, no protection-HTML, no hairpin through the public domain.

aaaah, you are right about the docker network, I did miss that detail. did you hapen to find (or file) a bug report about the non-working _APP_OPTIONS_ROUTER_PROTECTION=disabled? I searched github but didn't find anything related

I actually haven't filed one yet, and I couldn't find an open issue on GitHub either. It's definitely broken in 1.9.0, so feel free to file it if you want! At least that network alias trick keeps things moving for now.