You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/self-hosting/environment-variables.mdx
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -119,6 +119,8 @@ import { Callout } from 'fumadocs-ui/components/callout'
119
119
|`LITELLM_BASE_URL`| LiteLLM proxy base URL |
120
120
|`LITELLM_API_KEY`| Optional bearer token for LiteLLM |
121
121
122
+
On self-hosted deployments, the hosts configured in `OLLAMA_URL`, `VLLM_BASE_URL`, `LITELLM_BASE_URL`, `AZURE_OPENAI_ENDPOINT`, `AZURE_ANTHROPIC_ENDPOINT`, and `OCR_AZURE_ENDPOINT` can be reached on private networks without adding them to `EGRESS_ALLOWED_HOSTS`. Existing allowlists still apply. See [model host permissions](/platform/self-hosting/security#the-ssrf-boundary) for which requests this permits.
123
+
122
124
## Login Providers
123
125
124
126
Google, GitHub, and Microsoft sign-in, their callback URLs, and the `DISABLE_*_AUTH` switches are documented in [Authentication](/platform/self-hosting/authentication#social-login).
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/self-hosting/networking.mdx
+15-20Lines changed: 15 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -302,33 +302,28 @@ A proxy body limit of 250 MB accommodates all three defaults. If you lower the a
302
302
303
303
## Outbound connectivity
304
304
305
-
The app makes outbound calls to model providers, integration APIs, your email provider, object storage, and your telemetry backend. Whether `HTTP_PROXY` / `HTTPS_PROXY` apply depends on which of those paths a call takes — there is no single answer, and no global setting that covers all of them.
305
+
The shared HTTP transport honors `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` on both Bun and Node. This covers guarded HTTP requests, model-provider clients using Sim's fetch adapter, and AWS clients using Sim's shared request handler. It does not configure a global dispatcher or route non-HTTP protocols.
306
306
307
-
The server runs on Bun, and Bun's native `fetch` honors `$HTTP_PROXY`, `$HTTPS_PROXY`, and `$NO_PROXY`. Sim installs no global dispatcher, so every call that goes through the default `fetch` is proxied. The rest either build their own HTTP agent or speak a non-HTTP protocol.
307
+
Use an `http://` or `https://` proxy URL. For proxy authentication, both the username and password must be nonempty; partial credentials are refused. Lowercase variables take precedence over uppercase ones. `HTTP_PROXY` also applies to HTTPS when `HTTPS_PROXY` is unset. `NO_PROXY` matches the original destination hostname, with optional ports; it accepts exact names, domain suffixes, and `*`, but not CIDR ranges.
308
308
309
-
<Callout type="warn">
310
-
This depends on the runtime. The published images run Bun. If you build the standalone output and run it under Node instead, Node ignores these variables unless started with `NODE_USE_ENV_PROXY=1` (Node 22.21+ / 24.5+), and the `fetch`-based "Yes" rows stop being proxied — model providers, Resend, Gmail sending, the desktop update feed, and the telemetry relay. The Azure Blob, GCS and Azure Communication Services rows still hold: those SDKs read the proxy variables through their own agents rather than through `fetch`.
311
-
</Callout>
309
+
The transport resolves and validates destinations locally, then sends the approved numeric IP address in a CONNECT request. The original hostname remains in the HTTP Host header and TLS certificate verification. Both HTTP and HTTPS destinations require a proxy that accepts numeric CONNECT authorities. Proxy tunnels use HTTP/1.1; direct connections, including `NO_PROXY` matches, retain each client's HTTP/2 configuration. A proxy that requires hostname-only CONNECT or resolves names unavailable to the application cannot be used by this transport. Use NAT or transparent egress for those environments. Proxy failures never fall back to a direct connection.
310
+
311
+
An environment proxy is trusted deployment configuration, so its own address can be private or loopback. Its DNS answers are checked and pinned before connecting, and cloud metadata addresses are always refused. This trust does not change destination permissions: content URLs remain public-only, while configured private services still need the applicable [egress allowance](/platform/self-hosting/security#the-ssrf-boundary).
| Model providers reached over the default `fetch` — Anthropic, OpenAI, Google/Gemini, Vertex, Groq, Cerebras, xAI, Mistral, DeepSeek, OpenRouter, Together, Fireworks, Ollama, LiteLLM, and the other OpenAI-compatible providers | Yes |
316
-
| Email via Resend, Azure Communication Services, and Gmail sending | Yes |
317
-
| The desktop update feed's calls to GitHub | Yes |
318
-
| Object storage — Azure Blob and GCS | Yes — their SDK pipelines read the proxy variables |
319
-
| Everything through the SSRF guard — the HTTP block, tools, connectors, outbound webhooks, content fetches, MCP servers | No |
320
-
| Azure OpenAI, Azure Anthropic, vLLM | Only when the endpoint comes from `AZURE_OPENAI_ENDPOINT`, `AZURE_ANTHROPIC_ENDPOINT`, or `VLLM_BASE_URL`. An endpoint typed into the block is validated and pinned to its resolved IP, which bypasses the proxy |
321
-
| Amazon Bedrock, and object storage on S3 | No — the AWS SDK uses its own request handler |
322
-
| Email via SMTP | No — Nodemailer opens a raw TCP connection |
323
-
| Email via Amazon SES | No — the AWS SDK transport, over HTTPS |
315
+
| Shared guarded HTTP transport: tools, connectors, outbound webhooks, content fetches, MCP HTTP connections, and model-provider clients using Sim's fetch adapter | Yes, on Bun and Node, subject to the CONNECT requirements above |
316
+
| Amazon Bedrock and AWS integration clients using Sim's shared request handler | Yes, on Bun and Node |
317
+
| Object storage on Azure Blob and GCS; Azure Communication Services email | Yes, through the SDK's own proxy support |
318
+
| Native `fetch` paths and SDKs that use it, including Resend email, the desktop update feed, and the `/api/telemetry` relay | Yes on Bun; Node requires [`NODE_USE_ENV_PROXY=1`](https://nodejs.org/api/cli.html#node_use_env_proxy1) (Node 22.21+ / 24.0+) |
319
+
| Application object storage on S3; application email via Amazon SES | No, these clients use their own AWS SDK transport |
320
+
| Email via SMTP, Postgres, and Redis | No, these use raw TCP |
324
321
| OTLP export from the server SDK | No |
325
-
| The `/api/telemetry` relay that forwards browser events | Yes — it uses the default `fetch` |
326
-
| Postgres and Redis | No — raw TCP |
327
322
328
-
The practical consequence: a mandatory-egress-proxy environment can route most LLM traffic, Resend mail, and Azure/GCS storage through the proxy, but guarded integration calls, S3, Bedrock, SMTP, telemetry, and datastore traffic still need a transparent proxy or NAT-based egress.
323
+
An assigned organization gateway takes precedence over environment proxy settings. An explicit HTTP-block `proxyUrl` takes precedence over environment settings on direct routes, and is refused when organization policy requires a gateway.
329
324
330
325
<Callout type="info">
331
-
Set `NO_PROXY` for every destination that is not on the public internet, not just model endpoints. The app reaches the realtime server (`SOCKET_SERVER_URL`), the Presidio PII service (`PII_URL`), and itself (`INTERNAL_API_BASE_URL`) over the same default `fetch`, alongside self-hosted Ollama, LiteLLM, and vLLM — so a proxy that cannot reach your internal network breaks live updates and PII redaction, not only inference.
326
+
Set `NO_PROXY` for every destination that is not on the public internet, not just model endpoints. The app reaches the realtime server (`SOCKET_SERVER_URL`), the Presidio PII service (`PII_URL`), and itself (`INTERNAL_API_BASE_URL`) over HTTP, alongside self-hosted Ollama, LiteLLM, and vLLM — so a proxy that cannot reach your internal network breaks live updates and PII redaction, not only inference.
332
327
333
328
Set it in the application environment, not your shell — under `app.env` on Helm, or the service's `environment:` on Compose. On Helm the suffixes alone are not enough: the chart wires `SOCKET_SERVER_URL`, `PII_URL`, and `OLLAMA_URL` to bare Service names, which no domain suffix matches. Add those names too — `helm template` prints the rendered ones, and the prefix is the release name unless it already contains `sim`, in which case it is the release name alone:
334
329
@@ -349,9 +344,9 @@ The practical consequence: a mandatory-egress-proxy environment can route most L
349
344
```
350
345
</Callout>
351
346
352
-
### The per-request escape hatch
347
+
### Per-request proxies
353
348
354
-
The HTTP block's `proxyUrl` is honored per request by the SSRF guard, which builds a proxy agent for that call instead of pinning the target IP. It applies only to that path — connectors, content fetches, and MCP calls take a different guarded transport with no per-request proxy option.
349
+
The HTTP block's `proxyUrl` builds a proxy agent for that request. It applies only to the HTTP block; connectors, content fetches, and MCP calls use deployment proxy settings. This per-request path validates the destination locally but lets the proxy resolve the destination hostname, unlike the numeric CONNECT used by environment proxies.
355
350
356
351
<Callout type="warn">
357
352
`proxyUrl` must be an `http://` URL **and** must resolve to a public address. The guard validates the proxy host under a dedicated `proxy` profile that has no operator allowlist, so `EGRESS_ALLOWED_HOSTS` and `EGRESS_ALLOWED_IP_RANGES` do not reach it. A corporate proxy on an RFC 1918 address is refused even when that range is allowlisted for everything else. See [Security](/platform/self-hosting/security#the-ssrf-boundary).
Copy file name to clipboardExpand all lines: apps/docs/content/docs/platform/self-hosting/security.mdx
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -172,7 +172,7 @@ Resource ceilings for the in-process path:
172
172
173
173
## The SSRF boundary
174
174
175
-
By default Sim blocks outbound requests to private, reserved, and loopback addresses. This stops a workflow from being used to scan your internal network. Two things soften it on a self-hosted deployment: the provenances marked **Yes** below reach whatever you allowlist, and a configured endpoint, self-hosted service, or request target written as `localhost` or a loopback literal is reachable without any allowlist at all — a local Ollama or Jupyter is the ordinary case. That second carve-out stops short in two places: it does not lift the blocked-port list, and it does not extend to a database, cache, or mail connector on `localhost` — loopback is where Sim's own database and Redis listen, so reaching them has to be asked for. Neither softening applies on Sim Cloud. Every outbound request is classified by where its URL came from:
175
+
By default Sim blocks outbound requests to private, reserved, and loopback addresses. The allowances below let a self-hosted deployment reach services its operator has configured. The provenances marked **Yes** reach whatever you allowlist. A configured endpoint, self-hosted service, or request target written as `localhost` or a loopback literal is also reachable without an allowlist. That loopback allowance does not lift the blocked-port list or apply to database, cache, and mail connectors. These allowances do not apply on Sim Cloud. Every outbound request is classified by where its URL came from:
Content fetches never reach a private destination, allowlist or not — that is the class where SSRF is actually exploited. Nor does the proxy: it is the component deciding where everything else may go, so it is held to public destinations regardless of what the allowlist says.
186
+
The hosts in `OLLAMA_URL`, `VLLM_BASE_URL`, and `LITELLM_BASE_URL` are also trusted for self-hosted services. The hosts in `AZURE_OPENAI_ENDPOINT`, `AZURE_ANTHROPIC_ENDPOINT`, and `OCR_AZURE_ENDPOINT` are trusted for configured endpoints. These must be HTTP or HTTPS URLs without embedded credentials or wildcard hostnames. This trust covers the exact host or IP address across ports, without replacing your existing allowlists. It does not grant access through an HTTP block, a Function block's `fetch`, or a URL taken from content. Cloud metadata endpoints remain blocked, and model URL settings grant no private-network access on Sim Cloud.
187
+
188
+
Content fetches never reach a private destination, allowlist or not — that is the class where SSRF is actually exploited. The HTTP block's per-request proxy must also resolve to a public address regardless of the allowlist. Deployment proxies configured through `HTTP_PROXY` or `HTTPS_PROXY` can use private or loopback addresses; their DNS answers are checked and pinned, and metadata endpoints remain blocked. They do not expand which destinations a request may reach. See [Outbound connectivity](/platform/self-hosting/networking#outbound-connectivity).
187
189
188
190
Deployments frequently need to reach an internal service by name or address. Name the destinations:
0 commit comments