Deploy Syntic Code on AWS

If your engineering platform lives in Amazon Web Services, you will likely run Syntic Code on AWS compute: cloud development environments, EC2 instances that back remote workspaces, or build agents in your CI service. This page is about running the syntic CLI on that infrastructure. It does not change where the model runs; Syntic Code still reaches the Syntic model over the network through api.syntic.ai or your gateway.

Where the CLI runs

Common AWS placements are cloud IDEs and browser-based development environments, EC2 instances that host per-developer workspaces, and CodeBuild or self-hosted runners that execute automated tasks. In each case you install the pinned syntic binary into the machine image or bootstrap script so every instance comes up ready to use. Bake the install into your AMI or container image rather than fetching it at launch, which keeps startup fast and avoids depending on a download at the worst possible moment.

Credentials on AWS

Do not embed a long-lived API key in an AMI or task definition. Store the Syntic credential in AWS Secrets Manager or Systems Manager Parameter Store, grant the instance role permission to read only that secret, and load it into the environment at launch:

export SYNTIC_API_KEY="$(aws secretsmanager get-secret-value \
  --secret-id syntic/api-key --query SecretString --output text)"

For automation, prefer a dedicated service credential separate from human accounts, and scope the IAM role tightly so a compromised instance cannot read secrets it does not need.

Networking and scale

Instances in a private subnet reach api.syntic.ai through a NAT gateway or your egress proxy; allow that host, or your gateway host, in the relevant security groups. As the fleet grows, route all Syntic Code traffic through an internal gateway so you have one place to manage keys, quotas, and logging. Pin the binary version in your image pipeline so upgrades roll out as a reviewed change rather than drifting per instance.