Operate

The appliance runs in your AWS account and you operate it. This page covers reaching the instance, the appxenctl command, what you can and cannot change after launch, backups, and data retention.

Operations

SSH in with the SshCommand output, or reach the instance without opening port 22 at all through AWS Systems Manager Session Manager (the instance role already includes AmazonSSMManagedInstanceCore). Once on the instance, sudo appxenctl manages it:

Command	What it does
`status`	Containers, disk, memory, service health, Bedrock, JWT secrets, network guard.
`logs [service]`	Follow the last 200 log lines (every service, or one).
`restart [service]`	Recreate containers so they pick up edits to `.env`.
`backup now`	Dump Postgres and upload it to the backups bucket.
`backup list`	List the Postgres backups already in the bucket.
`restore <key>`	Restore a backup, safety-dumping the live database first.
`reset-admin [email]`	Set a temporary password and force a change at next sign-in.
`set-domain <name>` `set-domain --clear`	Switch between a trusted domain certificate and the self-signed one.
`set-brave-key` `set-brave-key --clear`	Set or remove the Brave Search API key for web search (see Web search).
`allow-upstream <name>` `allow-upstream --remove` `allow-upstream --list`	Let registered servers reach a server on the appliance itself or behind a single-label host name (see Register MCP servers).
`bedrock-check`	Re-run the Bedrock model-access probe.

Run sudo appxenctl help on the instance for the full command reference.

The services logs and restart accept are gateway, console-api, rag-engine, extension-runner, orchestrator, postgres and redis.

Changing settings later

First boot reads AdminEmail and DomainName once. Changing either in a stack update afterwards does not change the appliance: CloudFormation stops and starts the instance with the new user data and updates the stack's outputs, but first boot does not run again. Make these changes on the instance instead:

Domain: point the name's DNS A record at the ElasticIp output, then run sudo appxenctl set-domain <name>. sudo appxenctl set-domain --clear goes back to the self-signed certificate.
Admin: sign in and add the new administrator under Settings > Users. If you are locked out, sudo appxenctl reset-admin [email] gives an existing admin a temporary password (the instance ID by default) that must be changed at the next sign-in.

Changes that fail by design, and upgrades

Changing ImageId, KeyName or RootVolumeSize in a stack update fails and rolls back by design. Each of these replaces the instance, but the instance keeps its network interface, so CloudFormation cannot replace it, and the running appliance stays as it was.

Growing the root volume

Resize the EBS volume directly instead: run aws ec2 modify-volume to the new size, then grow the filesystem on the instance. A stack update is not the way to do that.

Moving to a new version (`ImageId` or `KeyName`)

For ImageId or KeyName, a new version is a new stack:

1
Run sudo appxenctl backup now on the current appliance.
2
Launch the new version as a new stack.
3
Copy the dump into the new stack's BackupsBucket under postgres/.
4
Run sudo appxenctl restore <key> on the new appliance.

What the Postgres dump carries, and what it does not. This carries only the Postgres RAG index. Your users, servers, extensions, workflows and schedules (DynamoDB) and your media and RAG documents (S3) are not part of a Postgres dump, so they stay behind in the old stack's retained resources, and the new stack starts without them.

Copy anything else you need across yourself, or keep the old stack's data resources reachable until a full migration path ships.

An upgrade tool for this is expected in a later release. Until then, treat a version upgrade as a fresh appliance that inherits only the RAG index.

Backups

First boot schedules a nightly Postgres backup: pg_dump -Fc to the backups bucket under the postgres/ prefix. That prefix has a 30-day lifecycle rule (7 days for noncurrent versions), so backups age out on their own.

Take a sudo appxenctl backup now before any risky change.
Find a backup to roll back to with sudo appxenctl backup list, then sudo appxenctl restore <key>.

restore writes a safety dump of the live database next to the backup before it replaces anything. The instance role has no permission to delete backups under postgres/, so old backups expire only through the bucket's lifecycle rule.

Data retention

Deleting the stack does not delete your data. These are retained on stack deletion, by design, so a mistaken or accidental delete can never take your data with it:

the five DynamoDB tables
the three S3 buckets (media, RAG documents, backups)
the SQS queue pair (the queue and its dead-letter queue)

If you are done with the appliance for good, delete those retained resources yourself once you have confirmed you no longer need them.

Inside the buckets, a deleted or overwritten media file or RAG document, and an unshared output, stays recoverable as a noncurrent version for 30 days before S3 removes it. The parts of an interrupted upload are removed after 7 days.