Deployment
Syntic Code always talks to the same Syntic model through api.syntic.ai, but the machines that run syntic can live almost anywhere: a developer’s laptop, a cloud workstation, a build agent, or a container spun up for a single task. This section is about placing the CLI into those environments cleanly. It does not change which model you use; it changes where the tool runs and how it reaches the network.
A single model, many environments
Whatever the environment, the pattern is the same. Install the syntic binary, give it credentials for the Syntic model, and make sure it can reach api.syntic.ai or your gateway. The differences between a plain laptop and a hardened cloud fleet come down to how you provision the machine, how you inject secrets, and how you constrain outbound traffic. The cloud pages here describe deploying Syntic Code within AWS, Google Cloud, and Azure accounts; they are about your compute footprint, not about model hosting.
What each page covers
- Feature Availability explains which capabilities depend on the environment and how to check what is available.
- Deploy on AWS, Google Cloud, and Azure show how to run Syntic Code on developer workstations and build agents in each cloud.
- Self-Hosted Endpoint covers pointing the CLI at an internal endpoint that fronts the Syntic model.
- Network Configuration documents proxies, firewalls, and the hosts you must allow.
- Development Containers describes running the agent inside a reproducible, isolated container.
Start with Feature Availability to understand what varies by environment, then pick the deployment target that matches your infrastructure.