connect

How declarations reach each other: network, env, iam and traffic.

A connect line joins two declarations, and its kind says what the connection means. One line usually becomes several cloud resources: an env connection from a service to a database on AWS is environment variables, a secret reference, a permission and a firewall rule.

the shape of a connection

connect env "web" -> "main"

connect, the kind, the quoted name it starts from, ->, and the quoted name it goes to. Both ends must be declared in the file (AK208). Direction matters, and each kind has one:

The four kinds

Kind	Written from → to	Means
`network`	network → what runs in it	Place the target inside the network.
`env`	consumer → what it uses	Give the consumer the target's connection details.
`iam`	consumer → what it may access	Grant the consumer's own identity access to the target.
`traffic`	sender → receiver	Route requests, schedules or messages from one to the other.

network

Places the target in the network: a VPC and its subnets on AWS, direct VPC egress on Cloud Run, a private peering for Cloud SQL, a delegated subnet and resource group on Azure. service and database are connected to the shared network net for you; anything declared with node that needs a network is connected by hand.

env

Hands the consumer the target's details as environment variables, prefixed by the target's name in upper case — database "main" gives MAIN_HOST, MAIN_PORT and so on. Which variables depends on what the target is, and on some targets which cloud — each declaration's page lists them per cloud. A database is the same everywhere:

Target	Variables
database	`_HOST _PORT _NAME _USER _PASSWORD`
cache	the host and port, and a URL or the password
bucket	the bucket's name and where it is
queue	what a client needs to publish and consume
secret	a reference to the secret, read at start
registry	the registry's address

Passwords and secrets arrive through the platform's own secrets channel and are read when the container starts. They never appear as a value in the plan or in Ackee's records of what it built.

iam

Grants the consumer's own identity — its task role on AWS, its service account on Google Cloud, its managed identity on Azure — the least access the target needs: read and write objects in a bucket, send and receive on a queue, push to a registry. It never grants everything on a resource.

ackee.ack

ackee 1
project "shop" {
  cloud  = "aws"
  region = "us-east-1"
}
service "web" {
  image = "public.ecr.aws/nginx/nginx:latest"
  port  = 80
}
# A provider-specific resource, declared exactly.
node "uploads" type "aws/s3-bucket@1" {
  name       = "uploads"
  versioning = true
}
connect env "web" -> "uploads"
connect iam "web" -> "uploads"

traffic

Connects whatever sends requests, schedules or messages to whatever receives them, and what it builds depends on the pair:

load balancer → service: routes the load balancer's requests to the service
load balancer → domain: points the domain's DNS record at the load balancer
load balancer → certificate: serves HTTPS with that certificate
schedule → job or service: runs the job, or calls the service, on the schedule
queue → function: makes the function the queue's consumer

Rules

Which kinds a declaration accepts, and in which direction, is listed for every type in the resource reference as its ports. A kind the two ends do not both accept is refused (AK403).
One connection per kind and pair of ends (AK216). An env and an iam connection between the same two are two different connections, and often both wanted.
Nothing connects to itself, and connections may not form a loop (AK215).
A connection drawn on the canvas may carry an id "..." at the end of its line. That id is how Ackee tells it apart across edits; leave it as it is. Connections you write by hand do not need one. Ackee may add one when a canvas edit would otherwise change the name a connection already deploys under.