Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.noxus.ai/llms.txt

Use this file to discover all available pages before exploring further.

Most of Noxus’s “intelligence” lives behind outbound calls. In a locked-down network, egress rules are what determine which features work. This page explains the categories and the impact of restricting each; the Endpoint reference lists the concrete hosts and ports to allowlist.

​
Categories of egress

​
Model providers

Every LLM, embedding, and reranker call is outbound to the provider’s API. If egress to a provider is blocked, models from that provider fail and any node/agent relying on them errors out (fallback models from a reachable provider still work). You must be able to reach at least one model provider, or self-host one (see minimal egress). Cloud provider models (Vertex AI, Azure OpenAI, AWS Bedrock) also require egress to that cloud’s auth/metadata endpoints, not just the inference endpoint.

​
Integrations & OAuth

Two distinct outbound flows:
  • Token exchange & refresh — after a user authorizes an integration, the backend calls the provider’s token endpoint (outbound) to exchange the code and later refresh it.
  • API calls — running an integration node calls the provider’s API (e.g. Google Drive, Microsoft Graph, Slack, Notion). Blocked egress to a provider disables that integration’s nodes and any agent tools that use it.
By default, OAuth for managed providers is brokered by the Noxus Control Service (NCS) — the secrets stay with NCS and the platform claims short-lived tokens. If you block NCS egress, use direct OAuth apps (your own client id/secret per provider) or static credentials instead.

​
Object storage

Files, run IO, and knowledge-base content live in object storage (Google Cloud Storage or S3-compatible). This egress is required unless you run an in-network S3-compatible store (e.g. MinIO) and point storage at it. Blocking it breaks uploads, file nodes, and KB ingestion.

​
Noxus Control Service (NCS)

NCS is Noxus’s optional control plane. Self-hosted deployments use it for:
  • OAuth brokering for managed integration providers.
  • Search / scrape relay for the built-in web tools.
  • On-prem checkin & auto-upgrade — the worker runs an outbound checkin (no inbound needed) that lets Noxus push compose/image updates.
NCS is outbound-only and optional. Without egress to it:
  • Auto-upgrade is disabled (upgrade manually instead).
  • NCS-brokered OAuth and the relayed search/scrape tools are unavailable — switch to direct OAuth apps and provider-native search keys.
  • The platform otherwise runs normally.

​
Telemetry (optional — disable for air-gap)

Error tracking (Sentry), product analytics (Mixpanel), and OpenTelemetry export are all outbound and optional. Leave their config unset and no telemetry egress occurs. For OTel, point the exporter at an in-network collector.

​
Web tools

The web-search and web-scrape tools call external services (a search API and a scraping API), typically via the NCS relay. Blocked egress disables those agent tools and any flow nodes that use them.

​
Outbound webhooks (run callbacks & relays)

When you pass a callback_url on a run, Noxus POSTs the result outbound to that URL on completion. This is the recommended pattern when you can’t accept inbound — you receive results without exposing anything. The target must be in your egress allowlist (and able to receive the call). Channel reply delivery (Slack/Teams/etc. responses) is likewise outbound to the provider.

​
Impact summary

Egress blockedImpact
A specific model providerThat provider’s models fail; reachable fallbacks still serve requests
All model providersNo LLM/embedding calls — agents and AI nodes can’t run. Self-host a model to recover
A specific integration hostThat integration’s nodes/tools fail; others unaffected
Object storageFile uploads, file nodes, and KB ingestion break
NCSNo auto-upgrade, no NCS-brokered OAuth/web tools; core platform fine
Telemetry hostsNone functional — telemetry is best-effort and optional
Your callback hostRun callback webhooks are not delivered (run still completes)

​
Running with minimal egress

To operate in a tightly restricted or air-gapped network:
1

Point models at an in-network endpoint

Use an OpenAI-compatible server inside your network (e.g. vLLM, Ollama, or a private Azure OpenAI). Configure the provider base_url to that host so no public model egress is needed.
2

Use direct OAuth apps or static credentials

Register your own OAuth applications per provider (your client id/secret) so token exchange goes straight to the provider, bypassing NCS. For providers that support static API tokens, enter those directly.
3

Run an in-network object store

Point storage at an S3-compatible endpoint (e.g. MinIO) reachable inside your network.
4

Disable telemetry

Leave the Sentry DSN, Mixpanel token, and OTel exporter endpoint unset (or set OTel to an internal collector).
5

Drop NCS, upgrade manually

Skip NCS egress entirely. Upgrade the deployment by replacing image tags / compose files yourself.
6

Allowlist only what remains

With the above, your required egress shrinks to your in-network endpoints plus whatever specific external integrations you deliberately keep. Verify against the Endpoint reference.
Web search/scrape, hosted-model providers, and managed-OAuth providers are the features most affected by an air-gap. Plan around in-network models and direct credentials, and the rest of the platform — flows, agents over your own models, knowledge bases, the editor — runs without public egress.