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 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.
| Declaration | AWS | Google Cloud | Azure |
|---|---|---|---|
service | ECS on Fargate | Cloud Run | Container Apps |
database | Amazon RDS | Cloud SQL | Azure Database flexible server |
worker | ECS on Fargate, no listener | Cloud Run worker pool | Container App, no ingress |
job | ECS task, run on demand | Cloud Run job | Container Apps job |
cache | ElastiCache Redis | Memorystore Redis | Azure Cache for Redis |
bucket | S3 | Cloud Storage | Storage account |
queue | SQS with SNS | Pub/Sub | Service Bus queue |
secret | Secrets Manager | Secret Manager | — (a Key Vault node) |
registry | ECR | Artifact Registry | Container Registry |
site | S3 with CloudFront | — (a static-site node and a domain) | Static Web App |
| shared network | VPC across two zones | VPC network | Virtual 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 1project "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.