Network Access
This page describes what network connections the AI Kit needs — what comes in, what goes out, and how to lay out an on-premise installation in your network.
Inbound connections (what reaches the AI Kit)
A single HTTP/HTTPS port. By default, the application listens on port 3000. Behind a reverse proxy, you typically expose 443 to clients and have the proxy forward to the AI Kit's port.
What uses inbound:
| Purpose | Source |
|---|---|
| Web user interface | Browsers of users in your workspaces. |
| Webhook triggers | External systems calling …/webhook/{workspace}/{workflow}/{key}. |
| OAuth callbacks | The user's browser, redirected from a third-party (Google, Microsoft) after authorizing the AI Kit. |
That is the full list. No other ports need to be reachable from outside.
Outbound connections (what the AI Kit calls)
Outbound is where most of the network activity happens. Depending on what your workspaces do, the AI Kit may connect to:
| Destination | Purpose | Required if you use |
|---|---|---|
api.openai.com | OpenAI chat / embeddings | OpenAI provider |
api.anthropic.com | Anthropic chat | Anthropic provider |
api.mistral.ai | Mistral chat / embeddings | Mistral provider |
| Your Ollama host | Self-hosted models | Ollama models |
| Your SMTP server | Outgoing mail (Send E-Mail integration) | mail-sending workflows |
| Your IMAP server | Incoming mail (E-Mail Inbox trigger) | mail-watching workflows |
| Your databases | Database Query / Listener integrations | DB workflows |
| Arbitrary URLs | HTTP Request integration | HTTP workflows |
accounts.google.com, oauth2.googleapis.com | OAuth + Google Calendar | Google integrations |
www.googleapis.com | Google Calendar / Drive APIs | Google integrations |
| Your MinIO endpoint | Cloud Storage trigger | MinIO workflows |
| Update / telemetry endpoints | Optional version check and (if enabled) metrics | always-on if not disabled |
The platform does not "phone home" with workspace content. Telemetry, where enabled, is limited to anonymous version + uptime data. Disable it via configuration if your environment requires zero outbound traffic that is not strictly functional.
A typical on-premise layout
Key choices:
- TLS at the proxy, not the AI Kit. Lets you use Let's Encrypt or your enterprise CA without touching the AI Kit.
- AI Kit listens only on the internal network. The proxy is the only thing that talks to it from outside.
- Strict outbound rules if your environment requires them. Allow-list only the provider domains you actually use.
Air-gapped installations
Some organizations cannot allow any outbound traffic. The AI Kit supports this, but with caveats:
- External AI providers are off the table. Use self-hosted Ollama instead — see Models → Ollama (Self-hosted).
- Email integrations require either an internal SMTP / IMAP server or routing through a one-way DMZ.
- OAuth-based integrations (Google Calendar) cannot work air-gapped because the user's browser must reach Google. Either accept this limitation or expose the OAuth flow through a tightly-controlled proxy.
- Telemetry must be explicitly disabled.
With these constraints accepted, the AI Kit runs fully within your network.
Webhook security
The webhook endpoint is the single most exposed surface. Two practical guidelines:
- Use a long, random shared key for every webhook. Treat the URL like a credential.
- Restrict source IPs at the proxy when the caller is a known service. Most CRMs and ticketing systems publish their IP ranges.
The AI Kit verifies the key on every call. Mismatches return HTTP 401 and are not logged as workflow runs.
TLS and certificate hygiene
- Use a valid certificate. Self-signed certificates work technically but cause confusion when third parties post webhooks to you.
- Rotate certificates before they expire. A monitoring check on certificate expiry pays for itself the first time it warns you.
- HSTS at the proxy. Once you commit to HTTPS, prevent accidental downgrades.