ackee
Docs/Ackee Script

Ackee Script

One file that describes your application and the cloud it runs on.

Ackee Script is a declarative language for describing an application and the cloud it runs on. You write one file, ackee.ack, that says what should exist — a service, the database it uses, how they are connected — and Ackee builds exactly that in your own AWS, Google Cloud or Azure account. You never describe the cloud resource by resource unless you want to.

ackee.ack
ackee 1
​
# A web service and the Postgres database it uses.
project "shop" {
cloud = "aws"
region = "us-east-1"
}
​
service "web" {
image = "public.ecr.aws/nginx/nginx:latest"
port = 80
}
​
database "main" {
engine = "postgres"
}
​
connect env "web" -> "main"

That is a complete script. On AWS it deploys a container on Fargate, a Postgres database on Amazon RDS, and the private network both of them run in — and everything the one connect line implies: the connection details in the service's environment, the database password kept in AWS Secrets Manager rather than in any file, the permission for the service to read it, and the firewall rule that lets the service reach the database and nothing else reach it.

The same file on every cloud

service, database and the rest of the table below are portable declarations: they mean the same thing on every cloud and become each cloud's own managed equivalent. Change cloud in the project block and the rest of the file can stay as it is.

DeclarationAWSGoogle CloudAzure
serviceECS on FargateCloud RunContainer Apps
databaseAmazon RDSCloud SQLAzure Database flexible server
workerECS on Fargate, no listenerCloud Run worker poolContainer App, no ingress
jobECS task, run on demandCloud Run jobContainer Apps job
cacheElastiCache RedisMemorystore RedisAzure Cache for Redis
bucketS3Cloud StorageStorage account
queueSQS with SNSPub/SubService Bus queue
secretSecrets ManagerSecret Manager— (a Key Vault node)
registryECRArtifact RegistryContainer Registry
siteS3 with CloudFront— (a static-site node and a domain)Static Web App
shared networkVPC across two zonesVPC networkVirtual network

Where clouds genuinely differ, the language says so instead of pretending. An ECS service is reached through a load balancer, which is its own resource, so public = true on AWS is an error that tells you what to declare instead (AK212).

How a script becomes infrastructure

  • Read and check. Ackee parses the file and checks every declaration. A problem is reported against the file — a code, a line and what to change, such as AK211 line 9:1: service "web" needs an image.
  • Plan. Ackee works out every resource that will be created, changed, replaced or destroyed, and shows you, declaration by declaration. Nothing changes yet.
  • Approve. You read the plan and approve it. A plan that replaces or destroys a database or a bucket asks you to type its name first.
  • Apply. Ackee builds the approved plan — exactly that plan, never a fresh one — in a short-lived, isolated runner inside your own cloud account, and streams what it is doing.

Two layers

Most files only need the portable declarations. When you need something specific to one cloud — a load balancer with your own domain, a queue, a bucket with versioning — you declare it exactly with node and a type from the catalogue, and wire it in with connect. The two layers mix freely in one file:

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"

Principles

  • Your account, your resources. Everything a script declares is built in your cloud account with your credentials, and stays there if you stop using Ackee.
  • Names are identity. A declaration's name is how Ackee recognises the resource on every later deploy. Renaming it replaces the resource; moving or reformatting it changes nothing.
  • Secrets never enter the file. A script refers to secrets; it never contains one. See Values and secrets.
  • Nothing is built that you were not shown. Every resource appears in the plan before it exists.
  • Errors speak the file's language. Every error carries a code, names the declaration and line it is about, and is explained in the error reference — including what the cloud said during a deploy.
  • A version-1 file keeps its meaning. Every file starts with ackee 1. Later versions may add to the language; they will not change what a valid version-1 file does.

Where to go next

Read Syntax for the shape of a file, then the declarations in order. To deploy a file, see Deploying a script. Every resource type you can name with node is listed, with its fields, in the resource reference.