Self-host on your own AWS

Run the full axonpush stack in your own AWS account, serverless, pay-per-use, and roughly $0/month at idle. One licence key, one command, your data never leaves your cloud.

Self-host runs the same stack the managed service does, inside your own AWS account: the Go API, gateway, worker and cron on Lambda, the Bun authsvc on Lambda, Aurora DSQL as the primary store, S3 for spilled event payloads, SQS for async work, and CloudFront in front of the API. There is no VPC, no NAT gateway, no container registry, and nothing that bills by the hour, it scales to zero when idle and linearly with traffic. See Architecture for how the pieces fit.

What you'll need

An AWS account with credentials in your shell (aws sts get-caller-identity succeeds)
The AWS CLI, Node (for the CDK CLI) and Go (to synthesize the CDK app)
A licence key (AXON-XXXXX-XXXXX-XXXXX-XXXXX)

No Docker, no domain, and no secrets to pre-create. The stack ships as prebuilt Lambda artifacts, so nothing is built on your machine and nothing is pulled from a registry.

Cost at idle

Nothing in the stack is always-on, so an unused deployment costs almost nothing.

Service	Idle cost
Lambda (API, gateway, worker, cron, authsvc)	$0, scale-to-zero, billed per invocation
Aurora DSQL	~$0, serverless, no idle cluster fee
S3 (spilled payloads)	~$0, cents of storage
CloudFront	~$0, free tier
SES (email)	$0 idle, billed per send

There is no NAT gateway, no EC2 or ECS, and no provisioned database host, so an idle deployment rounds to ~$0/month. Cost scales with real traffic.

Deploy

Get a licence key

Every self-host instance checks in with the axonpush control plane using a licence key. Licences are issued case by case; if you don’t have one yet, request access and you’ll receive a key in the form AXON-XXXXX-XXXXX-XXXXX-XXXXX. A key binds to the first AWS account that activates it.

Run the installer

curl -fsSL https://get.axonpush.xyz/install.sh | sh

It prompts for the licence key (or read it from LICENSE_KEY), then:

activates the licence against the control plane and binds it to your AWS account (this proves the key is good before anything is provisioned);
downloads the signed release bundle (prebuilt Go Lambdas + the authsvc zip + the CDK app);
runs cdk bootstrap and cdk deploy -c mode=selfhost, which provisions Aurora DSQL, the Lambdas, SQS and CloudFront, and self-bootstraps the database schema through a CloudFormation custom resource, no psql or goose on your machine;
wires the CloudFront domain back into the auth/app URLs and prints the result.

# non-interactive / CI
LICENSE_KEY=AXON-XXXXX-XXXXX-XXXXX-XXXXX AWS_REGION=us-west-2 \
  sh -c "$(curl -fsSL https://get.axonpush.xyz/install.sh)"

The deploy runs on the CloudFront default domain (d….cloudfront.net) with its managed certificate, so there is nothing to configure to get a working instance. To use your own domain, see Custom domain below.

Open the CloudFront URL the installer printed and sign up, the first account becomes the workspace owner. That’s it; the instance now shows up in the control console under your licence.

Custom domain

To serve on your own domain instead of the CloudFront default, provide an ACM certificate in us-east-1 (CloudFront requires it there) and re-run the deploy with the domain set:

export API_DOMAIN=axonpush.example.com
export API_CERT_ARN=arn:aws:acm:us-east-1:<account>:certificate/<id>
curl -fsSL https://get.axonpush.xyz/install.sh | sh

Then point a CNAME for API_DOMAIN at the CloudFront distribution from the deploy output.

Updating

Re-run the installer:

curl -fsSL https://get.axonpush.xyz/install.sh | sh

It pulls the current release bundle and redeploys in place; the self-bootstrap custom resource applies any new migrations idempotently. Your instance also checks in with the control plane hourly and picks up its current entitlement automatically.

Backups

Your data lives in two places: the Aurora DSQL cluster (events and the control plane) and the S3 bucket (spilled event payloads). Back up both on whatever cadence your retention policy requires. There is no DynamoDB and no other store to account for.

Tearing down

The Aurora DSQL cluster is created with deletion protection on, so a teardown never drops your data by accident. Delete the Axonpush CloudFormation stack (or cdk destroy), then disable deletion protection on the DSQL cluster and delete it, and empty and delete the S3 payload bucket.

Self-host keeps all event data in your account. Back up your Aurora DSQL cluster and the S3 payload bucket before any teardown or region move.

On this page