Deploy Syntic Code on Azure

Organizations standardized on Microsoft Azure can run Syntic Code on Azure Virtual Machines, Microsoft Dev Box, and Azure Pipelines or self-hosted agents. The CLI connects to the Syntic model over the network through api.syntic.ai or your gateway regardless of where it runs, so this page is about placing syntic onto Azure compute rather than hosting the model in Azure.

Where the CLI runs

Typical placements are Microsoft Dev Box environments that give developers a managed cloud workstation, Virtual Machines backing remote workspaces, and Azure Pipelines agents or self-hosted runners for automation. Install the pinned syntic binary into your VM image or Dev Box customization so machines are ready on first boot. Baking the CLI into the image keeps provisioning fast and turns upgrades into a controlled change to the image definition instead of ad-hoc per-machine installs.

Credentials on Azure

Do not store the Syntic key in an image or pipeline variable in plain text. Keep it in Azure Key Vault, grant the VM’s managed identity access to that specific secret, and load it into the environment at startup:

export SYNTIC_API_KEY="$(az keyvault secret show \
  --vault-name syntic-kv --name api-key --query value -o tsv)"

Use a managed identity rather than a stored service-principal secret where possible, scope its Key Vault access policy to only the required secret, and separate automation credentials from developer ones.

Networking and scale

VMs in a private subnet reach the internet through Azure NAT Gateway or your egress proxy and firewall; allow api.syntic.ai, or your gateway host, on those routes. As the fleet grows, route all traffic through an internal LLM gateway to centralize keys, quotas, and audit logs, and pin the binary version in your image pipeline so every Dev Box and agent runs the same release.