Installing on Amazon Web Services

On AWS, Tricryption runs as the Ubuntu packages on an EC2 instance, with its key database on Amazon RDS. The Gateway and the Console run either beside the key server or as container images on ECS Fargate. Nothing about the product changes on AWS: the same packages are installed and the same two provisioning tools run on the instance. What is AWS's is the network, the roles, the database instance and how you reach the machine.

The shape

Part	How it is set up
Key server	an EC2 instance running Canonical's Ubuntu 24.04 image (the standard or the minimal server image), in a private subnet, with no public IP address, IMDSv2 required and an encrypted root volume; tricryption-ks installed and provisioned by tricryption-ks-provision
Key database	Amazon RDS for PostgreSQL 16, not publicly accessible, encrypted, with rds.force_ssl=1. The key server connects with sslmode=verify-full against the region's RDS CA bundle.
Administration	AWS Systems Manager Session Manager only: no inbound rule from anywhere, no key pair, no bastion. Any ssh runs inside an SSM port-forwarding session to the instance's own sshd.
Console and Gateway on the instance	tricryption-console-gateway and tricryption-node installed beside the key server and provisioned by tricryption-tier-provision, as on any Ubuntu host
Console and Gateway on ECS Fargate	the two container images in your Amazon ECR, run as Fargate services in the private subnets with assignPublicIp=DISABLED. Every secret is a SecureString in SSM Parameter Store, given to the task by valueFrom. No secret is in a task-definition environment entry or an image layer. The root filesystem is read-only.

The instance's security group admits the key server's port only from the tasks' security group. The RDS security group admits PostgreSQL only from the instance and the tasks. The instance role carries AmazonSSMManagedInstanceCore, plus read access to this deployment's RDS secret and SSM path, and nothing else. The task role carries no permissions.

What you supply

• An AWS account and a region, and credentials for them. No IAM user or access key is needed: administration is through your own sign-in and Session Manager.
• The release's four .deb packages and the two container images, pushed to your ECR repositories. See What a release contains.
• The release signer's certificate, CA certificate and CRL, to register the release with the key server.
• The RDS database role and its empty database, created over verify-full before the key server is provisioned.

Provisioning on the instance

On the instance, install the packages as on any Ubuntu host. Then provision the key server against RDS. The bind address is the instance's private address, so tasks in the VPC can reach it:

sudo tricryption-ks-provision --xauth-policy --bind-host <private-address> --db <database> --db-role <role> --db-host <rds-endpoint> --db-password-file <db-password-file> --db-sslmode verify-full --db-sslrootcert /etc/pisoft-deploy/rds-ca.pem --db-servername <rds-endpoint>

/etc/pisoft-deploy/rds-ca.pem is the region's RDS CA bundle, readable by the service user. Keep it outside /etc/pisoft: that directory belongs to the packages, and apt purge removes only what provisioning wrote there, then the directory itself if it is empty. A file you place inside it keeps /etc/pisoft behind after a purge. Then provision the Console and the Gateway beside it as in step 3 of the Linux page.

For the ECS tasks, tricryption-tier-provision --identity-out writes the Gateway's and the Console's identities and secrets. Each is written to one file, named as the images read it: the key server's anchor, the Gateway's own certificate pair, the audit reader's database password and CA, and the Console's administrator password. Store each as a SecureString under your deployment's SSM path, and the non-secret settings as String. The region's RDS CA bundle can exceed 4 KB, so store the two CA-bundle parameters in the advanced tier.

When the Gateway delegates for registered services (the operator bootstrap), add --identity-delegation to --identity-out. It also writes the delegator's certificate and key and the service registry, as TE_GATEWAY_CLIENT_CERT_PEM, TE_GATEWAY_CLIENT_KEY_PEM and TE_GATEWAY_SERVICE_REGISTRY_JSON. Export after you register a service: the ECS Gateway reads the registry it was given. A service registered later is refused there with 403 SERVICE_NOT_REGISTERED until you export again and roll the tasks. A second export needs a certificate subject of its own (--identity-cn): a subject already enrolled is refused.

Sign-in with your identity provider

The Gateway's OpenID Connect sign-in works on AWS as on any host. The identity provider must be reachable from the instance and from the tasks under the same issuer URL the browser uses. A private DNS name in the VPC (for example an AWS Cloud Map private namespace) and the provider's own TLS certificate for that name work.

• On the instance, provision the tier with --oidc-config <file> and --public-origin <https-origin>. Put the client secrets and the provider's CA where the configuration names them, readable by the service user, and outside /etc/pisoft.
• On ECS, the Gateway image reads its configuration from SSM, each by valueFrom: TE_GATEWAY_OIDC_CONFIG_JSON (the configuration, its secret and CA paths naming /run/tricryption/oidc-secret-<id> and /run/tricryption/oidc-ca.pem), TE_GATEWAY_OIDC_CA_PEM, and one TE_GATEWAY_OIDC_SECRET_<ID> per client secret, as SecureString. TE_GATEWAY_PUBLIC_ORIGIN is a plain environment setting. Write each value without a trailing newline.
• The public origin is an HTTPS origin in front of the Gateway: a load balancer, or a TLS terminator of your own. The browser's sign-in page and its redirects use it.

Operational metrics

Provision the tier with --metrics-addr 127.0.0.1:9464 and run the scrape proxy on the instance, as the monitoring page describes. Run the proxy as the systemd service the recipe ships, so it starts again after a reboot. The proxy is the distribution's nginx. On Ubuntu, installing it also starts the distribution's own nginx.service, with its default site on port 80; stop it and keep it from starting with the machine, because the proxy runs as a unit of its own:

sudo apt-get install -y nginx
sudo systemctl disable --now nginx.service

Metrics from the ECS tasks were not part of the qualified run.

The MCP server on the instance

The Console package ships the MCP server with the Python starter, under /opt/pisoft/tricryption/console-gateway/examples/python-agent-starter. Ubuntu's server image has no venv module for its Python. Install it only if python3 -c 'import ensurepip' fails, then install the SDK from the shipped hash lock:

sudo apt-get install -y python3-venv
python3 -m venv ~/te-mcp/venv
~/te-mcp/venv/bin/python -m pip install --require-hashes --no-deps -r /opt/pisoft/tricryption/console-gateway/examples/python-agent-starter/mcp/requirements.lock

To serve many users, follow Serving many users over Streamable HTTP.

Security events

The export itself, its envelope and its removal are on Exporting security events. This section covers what is specific to Amazon RDS.

The security-event export reads the key database's audit table by logical replication. On RDS, the instance's parameter group sets rds.logical_replication=1. The parameter is static: it takes effect after a reboot, or from the start for an instance created from that group. The capture role is granted rds_replication. The capture role, its column grants and the publication are under Your own PostgreSQL.

On the instance, provision the tier with --security-events-dir /var/lib/pisoft/console-gateway/security-events. Then drain that outbox on the instance with the dispatcher the release ships. To evaluate with the reference overlay, also pass --security-events-deployment tricryption-eval. The overlay indexes that one deployment, and te-siem.sh check reports an event under any other name as refused. If the overlay's path to RDS is interrupted, its capture task stops: run te-siem.sh resume once the path is back.

Upgrading

Install the newer release's packages on the instance; the packages restart what was running. At code-signing level 2, then register the new release:

sudo tricryption-tier-provision --register-release --signer-cert <signer.pem> --signer-ca <release-ca.pem> --signer-crl <release-ca.crl.der>

The ECS tasks keep running on their registered release, and stay admitted at level 2. See Upgrade on Linux.

A newer release signed by a different release signer than the one registered is admitted at level 0 until it is registered with its own signer's certificate, CA certificate and CRL. Register it before you raise the level. To move the ECS tasks, push the newer release's images and point the services at them; each new task is admitted on the release it carries, and the old tasks stop once the new ones are ready.

What was qualified, and what was not

The shape above was qualified in four fresh environments in one region, and once more by upgrade:

• By upgrade, on 2026-10-26, at the production size: Canonical's standard Ubuntu 24.04 image (ubuntu-noble-24.04-amd64-server-20261023), RDS for PostgreSQL 16.15 db.m7g.large over verify-full. Release 8.1.0+3272.ge71a9e15, the release the 2026-10-20 run qualified, was installed and provisioned, then upgraded on the instance and on ECS to 8.1.0+3507.g8a95ed57 and 8.1.0+3517.g7ed8e8fa, each signed by a different release signer. The keys, the key server's entries and the registered system stayed; each newer release was admitted at level 0 until registered, then at level 2. Everything the 2026-10-20 run checked passed again on the newer releases. Also: a service signing in with an access token from the identity provider (subjectToken), at the instance's Gateway and at the ECS Gateway; the MCP server shipped with the Console, serving two users over Streamable HTTP from the instance; the encrypt limit, where 16,777,215 bytes encrypt and one byte more is refused with 400 before the key server is asked; and a refused request leaving its audit row in the key database on RDS.
• The production size again, on 2026-10-20, with sign-in, metrics, security events and the Python starter: EC2 m7i.xlarge on Canonical's standard Ubuntu 24.04 image (ubuntu-noble-24.04-amd64-server-20261017), RDS for PostgreSQL 16 db.m7g.large over verify-full with rds.logical_replication=1, and the Gateway and the Console on ECS Fargate at 0.5 vCPU and 1 GiB per task. A Keycloak identity provider ran as an ECS service in the same VPC, its configuration in its own database on the same RDS instance. Everything the 2026-10-14 run checked passed again. So did OpenID Connect sign-in at the instance's Gateway and at the ECS Gateway (including the Gateway's own sign-in page in a browser), and its refusals: a replayed code, a tampered state, and the provider down then back. Also: the metrics listener with its scrape proxy (the target-down alert fired and cleared, and the proxy came back after a reboot), security events from the Gateway and from the key server's audit table on RDS, both found in the overlay's index, and the Python starter and its workflow adapter through the delegation layer on ECS.
• The production size, on 2026-10-14: EC2 m7i.xlarge (4 vCPU, 16 GiB) on Canonical's standard Ubuntu 24.04 image, RDS for PostgreSQL 16 db.m7g.large over verify-full, and the Gateway and the Console on ECS Fargate at 0.5 vCPU and 1 GiB per task. The checks covered install, provisioning, readiness, the acceptance suite, key round trips, the release checksums and signature, database TLS (wrong CA, wrong name and sslmode=disable each refused), the running key server refusing a database CA it does not trust, reboot, upgrade, the level-2 upgrade, a changed payload byte refused at admission, removal and reinstall, purge, and the remote engine. On ECS they covered task readiness, task replacement after a stop, and a tampered image refused at admission.
• On 2026-10-13, Canonical's standard Ubuntu 24.04 image on EC2 m7i-flex.large (2 vCPU, 8 GiB) with RDS db.t4g.micro, and the Gateway and the Console on ECS Fargate at the same task size. The checks covered the same lifecycle without purge.
• On 2026-10-13, Canonical's minimal Ubuntu 24.04 image on EC2 m7i-flex.large with a local PostgreSQL. The checks covered the same lifecycle, including purge.

Nothing in the procedure changes with the instance class. Multi-AZ RDS, a load balancer in front of the Gateway and the Console, and more than one task per service were not part of any run.

Qualified at engine master 8a95ed5717f6.