Deploying AariaSec in your own cloud

Most people run AariaSec as a native app on the machine the agent runs on. This page is the other path: running it as a platform inside your own AWS account, on your own Kubernetes cluster, for teams whose agents already live in the cloud rather than on laptops.

The distinction that matters: this is your infrastructure. AariaSec does not operate it, cannot reach it, and never receives a copy of anything it observes. There is no AariaSec-run service in the data path — the same claim the native app makes, unchanged. What differs is only whose hardware the software runs on.

What gets deployed

One terraform apply provisions, in your account:

Agents then point their HTTPS_PROXY at the in-cluster proxy service, and everything else — behavioural fingerprinting, the rule library, containment — works exactly as it does on a laptop install.

Before you start

The Free Plan will stop you

New AWS accounts default to a Free Plan that hard-blocks launching any EC2 instance type outside the free tier. The node group will fail with:

InvalidParameterCombination - The specified instance type is not eligible for Free Tier.

Free-tier-eligible types (1 GB RAM) cannot host this workload — after Kubernetes' own system pods take their share, there is not enough left to run anything. Upgrade the account to a paid plan before starting. The EKS control plane itself provisions fine on a Free Plan, so the failure appears ~15 minutes in, after the slowest part has already completed.

Step 1 — Get the images into your registry

The platform images live in your account's ECR, not ours — the Terraform resolves the registry from whatever account you apply into. Contact us for pull credentials to the source images, then mirror them:

# Authenticate to the source registry with the credentials you were given,
# then mirror both images into your own account's ECR.
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
REGION=us-west-2

for img in aariasec-platform aariasec-dashboard; do
 aws ecr create-repository --repository-name "$img" --region "$REGION" \
 --image-scanning-configuration scanOnPush=true || true

 docker pull "<source-registry>/$img:0.1.0"
 docker tag "<source-registry>/$img:0.1.0" \
 "$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/$img:0.1.0"
 docker push "$ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/$img:0.1.0"
done

Once they are in your ECR, the cluster pulls them using the node group's own IAM role. There is no registry credential to distribute to the cluster, and nothing to rotate later.

Both images are published for linux/amd64 and linux/arm64, so they run on standard nodes and on Graviton.

Step 2 — Configure

cd deploy/terraform/aws
cp terraform.tfvars.example terraform.tfvars

The settings that matter most:

Object Lock is permanent — choose the retention deliberately

The audit bucket uses S3 Object Lock in COMPLIANCE mode, which is what makes the audit trail genuinely tamper-proof: once written, an object cannot be deleted or altered until its retention expires — not by you, not by your root account, not by AWS support. That is the point of it.

It also means the default 365-day retention will keep that bucket, and anything written to it, in your account for a year. For production that is usually correct. If you are evaluating and intend to tear down afterwards, set s3_object_lock_days = 1 before applying, or plan to leave the bucket behind.

Step 3 — Apply

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Expect 20–30 minutes. The EKS control plane takes 10–15 of that, and the node group a further 5–10 — both are normal and neither produces useful output while waiting. The Helm release runs last, and is configured to block until pods are actually healthy, so a successful apply means a genuinely running system rather than resources that merely exist.

Then:

$(terraform output -raw kubeconfig_command)
kubectl get pods -n aariasec

Every pod should reach Running with all containers ready.

Step 4 — Reach the dashboard

Zero public exposure, good for bring-up:

kubectl port-forward -n aariasec svc/aariasec-dashboard 3000:3000

The first-boot admin credentials are printed by the API pod:

kubectl logs -n aariasec deploy/aariasec-api | grep -i "initial admin"

Change that password immediately. For ongoing access, set public_domain and allowed_dashboard_cidrs and the chart configures an HTTPS ingress instead.

Step 5 — Point your agents at the proxy

Agents in the same VPC reach the proxy service directly:

export HTTPS_PROXY=http://aariasec-proxy.aariasec.svc.cluster.local:8080
export HTTP_PROXY=$HTTPS_PROXY

Agents elsewhere — CI, laptops, another account — need the proxy exposed on an internal load balancer, reached over VPN or PrivateLink. Do not put it on the public internet.

For traffic to be inspected rather than merely routed, the proxy's CA must be trusted by the agent. Content is hashed before anything is written to disk; the certificate enables metadata extraction, not content retention.

Step 6 — Verify the privacy guarantee yourself

Do not take our word for it. After traffic has been flowing for an hour:

kubectl exec -n aariasec deploy/aariasec-api -- \
 python scripts/verify_no_raw_content.py --strict

Expected: RESULT: PASS. This scans the actual database in your cluster for raw prompt or response text. If it ever fails, stop and contact us — that is a violated guarantee, not a tuning issue.

Upgrades

Point the image tags at the new version and re-apply. The chart performs a rolling update; database migrations run automatically.

terraform apply

Tearing down

terraform destroy

Two things will deliberately refuse to disappear, and both are working as intended:

• The RDS instance, if deletion protection is on (the default in prod).
• The audit bucket, if objects are still inside their Object Lock retention window — see above. Nothing can delete those before retention expires.

Verify the teardown against AWS rather than trusting the command's exit code — NAT gateways, Elastic IPs, and EBS volumes are the usual stragglers, and they bill by the hour whether or not you remember them:

aws ec2 describe-nat-gateways --filter "Name=state,Values=available,pending"
aws ec2 describe-addresses
aws ec2 describe-volumes

Other clouds

Terraform for Azure and GCP exists and follows the same shape. Written walkthroughs for those are not finished yet — the AWS path above is the one that has actually been exercised end to end, and we would rather point you at that than at a guide nobody has followed.