AppXen Platform

What you get

• MCP Gateway Pro — one endpoint for every MCP server, REST API and built-in tool (RAG, media and web search) your agents use, reached by Claude Code, Claude Desktop, Cursor and other MCP clients with an API key, over Streamable HTTP or SSE. Learn more
• RAG Engine — upload documents and search them from any agent. Embeddings come from Amazon Titan on your Bedrock; vectors are stored in Postgres with pgvector on the instance. Learn more
• Agent Orchestrator — multi-step agent workflows written in markdown, run on Amazon Bedrock (Claude and Nova), with approval gates, scheduled runs and a live dashboard. Learn more
• Console — one sign-in for all of it: password sign-in (passkeys once the appliance has a domain), users and roles, a read-only view of the model registry, and a health panel that checks your AWS identity, every service and Bedrock access for each model.

What it costs

The software fee is set per instance type and billed by AWS Marketplace: $0.149 per instance-hour, or $949 per year in place of the hourly rate, on the large types (t3.large, t3a.large, m6i.large and m6a.large), and $0.199 per instance-hour, or $1,299 per year, on the xlarge types (t3.xlarge, t3a.xlarge, m6i.xlarge and m6a.xlarge). The infrastructure it runs on, and the Amazon Bedrock models it calls, are billed by AWS to your account at AWS prices. AppXen does not meter requests, storage or tokens.

An estimate, not a quote: us-east-1, one t3.large running all month, a 50 GiB root volume, light usage, AWS prices of 2026-09-29. The annual figure is the yearly price divided by twelve. Bedrock usage is extra and depends on the models and tokens you use; see Amazon Bedrock pricing. A t3a or m6a AMD instance type costs less where your Availability Zone offers it.

How it deploys

1. Prepare Amazon Bedrock (once, before you launch). See the section below.
2. Subscribe on AWS Marketplace and launch the CloudFormation template in the AWS account and Region where the appliance should run. You fill in eight parameters.
3. Wait a few minutes after the stack reaches CREATE_COMPLETE while first boot generates secrets and starts every service.
4. Sign in. Open the stack's ConsoleUrl output and accept the self-signed certificate warning (unless you set a domain). Sign in as the AdminEmail you entered, with the stack's InstanceId output as the temporary password. The console makes you change it at once.
5. Check the health panel on the dashboard home page, then create an API key and connect your MCP client.

The eight parameters

Every parameter in full, with the Availability Zone exception and the quotas, is in the deployment guide.

Before you launch: Amazon Bedrock

The appliance calls Amazon Bedrock in the same Region as the stack, using six models by default. Anthropic's Claude models need a one-time step that an account administrator does in that Region:

1. Submit Anthropic's one-time use-case form in the Bedrock console.
2. Invoke each of the three Claude models once, for example in the Bedrock console's model playground, to create your account's AWS Marketplace subscription for it.

• Anthropic Claude Sonnet 4.5
• Anthropic Claude Opus 4.6
• Anthropic Claude Haiku 4.5
• Amazon Nova Lite
• Amazon Nova Pro
• Amazon Titan Text Embeddings V2 (RAG document embeddings)

Amazon Nova and Amazon Titan need no such step. If you skip it, the stack still launches and first boot still finishes: the health panel and sudo appxenctl bedrock-check then report the Claude models as denied until an administrator completes it, and the other models keep working. The Region details are in the deployment guide.

What the stack creates

• Its own VPC (10.0.0.0/16) with one public subnet, an internet gateway and a route table, so the stack depends on no network you already have
• One security group: HTTP and HTTPS open, SSH only from the CIDR you supply
• One EC2 instance running the AppXen Platform AMI, with an Elastic IP, an encrypted gp3 root volume and IMDSv2 required
• Five DynamoDB tables, three S3 buckets (media, RAG documents, backups) and an SQS queue with a dead-letter queue
• One least-privilege IAM instance role. The template creates no access keys.

Instance types and Region

The default is a t3.large (2 vCPU, 8 GiB), which runs the whole stack (five product services plus Postgres and Redis) for small-to-medium teams. Larger workloads should size up to one of the other seven types: t3.xlarge, t3a.large, t3a.xlarge, m6i.large, m6i.xlarge, m6a.large or m6a.xlarge.

Region: US East (N. Virginia), us-east-1, at launch.

Where your data goes

Everything runs on one instance in your account, on your own Amazon Bedrock access. There is no AppXen-hosted service in the loop. Every product reads and writes your own DynamoDB tables, S3 buckets and SQS queue, and the Postgres on the instance, using the instance's own IAM role, never long-lived access keys. Secrets are generated on the instance at first boot and stored only there.

By itself the appliance connects to AWS services in your account, to Let's Encrypt once you give it a domain, and to what its Ubuntu operating system calls on its own (package servers, the Snap Store for the Systems Manager agent, time synchronisation). Beyond that it connects to what you set up or ask for: the MCP servers and REST APIs you register, and Brave Search if you add a Brave Search API key. Amazon Bedrock may serve a request from another Region of your stack's geography through a cross-Region inference profile. The full list is on the Network & IAM page.

Operating it

You run the appliance, with AppXen's own tooling on the instance. Reach it with SSH, or through AWS Systems Manager Session Manager without opening port 22, and use sudo appxenctl:

A nightly Postgres backup runs on its own. Upgrade notes, backups and every command are in the operations guide.