AWS Marketplace

Launch polign_db from AWS Marketplace as one EC2 instance in front of an S3 bucket in your own account. The listing charges nothing for the software. You pay AWS for the instance and the bucket.

Open the listing on AWS Marketplace →

What you get

An Amazon Linux 2023 image for Graviton (arm64) instances with the polign_db release binaries installed, and a CloudFormation template that launches it. The bucket is the database: vectors, indexes, and the write log all live there, and the instance is a serving tier in front of it. Replacing the instance loses nothing.

The template creates:

the S3 bucket, with encryption at rest turned on
an instance role that can reach that one bucket and nothing else
a security group limited to the address range you name
an internal load balancer, if you ask for one

The image holds no credentials, no bucket name, and no access keys. The instance reaches S3 through its role.

Launch

Subscribe on the listing page, choose the CloudFormation delivery option, and fill in the stack parameters. These are the ones worth attention:

Parameter	What to set
`AllowedCidr`	The address range allowed to reach ports 23000 (HTTP) and 23001 (gRPC). Use your VPC range. The template refuses `0.0.0.0/0`.
`SubnetIds`	A private subnet with a route to S3, through a NAT gateway or an S3 gateway endpoint. The endpoint is cheaper.
`InstanceType`	Serving from the bucket is bound by network bandwidth and by how much of the working set fits in memory, so prefer memory over vCPUs.
`BucketName`	Leave empty and the stack creates one. A bucket the stack created is kept when you delete the stack, so your data outlives it.
`StoreRoleArn`	Leave empty for a bucket in this account. See a bucket in another account for the other case.

Verify

The stack outputs an HTTP endpoint. The server requires an API key, and first boot creates one on the instance. Open a Session Manager session and copy it into your secret manager:

aws ssm start-session --target <instance-id>
sudo cat /var/lib/polign/data-key

Then, from a machine inside AllowedCidr, set KEY to that value and run:

curl "$ENDPOINT/healthz"

curl -X PUT "$ENDPOINT/v1/collections/docs/vectors/a" \
  -H "Authorization: Bearer $KEY" \
  -d '{"values":[1,0,0],"metadata":{"label":"first"}}'

curl -X POST "$ENDPOINT/v1/collections/docs/query" \
  -H "Authorization: Bearer $KEY" \
  -d '{"values":[0.9,0.1,0],"k":5}'

A collection is created by the first write and takes its size from the first vector. The Python SDK and the HTTP API work against this endpoint the same way they work anywhere else.

Security

Every data request needs the API key. First boot writes it to /var/lib/polign/data-key, readable only by the service account, and logs only its public id.
The security group is the second boundary. Never open 23000 or 23001 to the internet. The load balancer is internal for the same reason.
No inbound port is needed for shell access. Session Manager covers it, and the template opens no SSH port.
The bucket uses S3 server-side encryption and the root volume is encrypted at launch.

With server-side encryption, S3 still sees your data in the clear on every request. To keep the bucket from ever holding readable data, put a keyring file on the instance and name it as POLIGN_STORE_ENCRYPTION_KEY_FILE in /etc/polign/server.env before the first write. Every object is then encrypted inside the server process, and the local disk cache is sealed under the same keys. The security page covers how that works.

A bucket in another account

An account cannot give its own role access to another account's bucket, so this case uses role assumption. Create a role in the bucket's account, trust the stack's InstanceRoleArn output in that role's trust policy, and pass the role as StoreRoleArn. The server signs every request with short-lived credentials from that role. No access keys are involved either way.

# what the template writes to /etc/polign/server.env
POLIGN_STORE=s3://their-bucket/db
POLIGN_STORE_ROLE_ARN=arn:aws:iam::222222222222:role/polign-store
POLIGN_STORE_EXTERNAL_ID=optional-if-their-trust-policy-requires-one
POLIGN_STORE_REGION=eu-west-1   # only if that bucket is in another region

Operate

Configuration lives in /etc/polign/server.env. Edit it and run sudo systemctl restart polign-server.
Extra server flags go in POLIGN_EXTRA_ARGS in the same file.
Logs: journalctl -u polign-server.
Index maintenance runs inside the server every 30 minutes. There is nothing to schedule.

Operate in production covers tuning, scaling out, and controlling the bill.

Upgrade

New releases arrive as new versions of the listing. Update the stack with the new image and let it replace the instance. The bucket carries the data, so the replacement comes back on the same collections. Take a bucket snapshot first if you want a way back.

Remove

Delete the stack. The instance, role, security group, and load balancer go with it. A bucket the stack created is kept, so delete it yourself once you are sure you no longer need the data.