Network configuration

Syntic Code is useless if it cannot reach the Syntic model, so in locked-down corporate networks the difference between a smooth rollout and a stream of support tickets is usually network configuration. This page covers the outbound connectivity the CLI needs, how to work through proxies and firewalls, and how to verify that a given machine can talk to the model.

What Syntic Code needs to reach

At minimum, syntic must make outbound HTTPS connections to api.syntic.ai, or to the gateway or self-hosted endpoint you have put in its place. If you use MCP servers, the agent also needs to reach whatever hosts those servers live on. Downloads for installation and upgrades come from your release mirror or the official download host. Beyond these, Syntic Code does not require inbound connectivity, so firewalls can block all inbound traffic to developer machines without affecting it.

Working through a proxy

In networks that route all egress through an HTTP proxy, honor the standard proxy environment variables so the CLI and its dependencies use them:

export HTTPS_PROXY="http://proxy.internal.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"

If the proxy performs TLS inspection with a private certificate authority, make sure that CA is installed in the system trust store, otherwise the CLI’s TLS connections to the endpoint will fail with certificate errors.

Allowlisting and verification

Where egress is denied by default, add api.syntic.ai (or your gateway host) and your MCP hosts to the firewall allowlist rather than opening broad ranges. After configuring the network, confirm connectivity from a representative machine before rolling out:

syntic doctor

The check reports whether the endpoint is reachable and whether credentials work, which quickly distinguishes a network problem from an authentication one. Document the required hosts and proxy settings so new environments can be provisioned correctly the first time.