# Host it yourself

> Runs Mindset inside your own AWS account, operates it from Backstage, and keeps it current release by release.

Builders work from a coding agent and operators from an AI client, both through the MCP server, or in the Studio. In Mindset, an agent is a prompt and a model, held to an order by a script when needed. It uses connections to outside systems, operations on them, functions and widgets. Every change is a version, and every execution is a run. Every piece sits on one security and compliance layer: the org sets its posture once, and every agent works under it, with the audit trail and, once an admin turns it on, personal data redaction. The platform runs in your own cloud (AWS, GCP or Azure) or is hosted by Mindset. Your app reaches agents through the SDK, your server through the API, and people through the Hub and schedules. Highlighted: Operators.

Most organizations use Mindset as a hosted service. Self-hosting is for teams whose data or contracts require it. The whole product ships as one container image, deployed from a CloudFormation template with the AWS CLI. Your team performs every action inside the account, and nobody from Mindset needs standing access.

## What lands in your account

Choose **Create VPC** for a new VPC, or **Adopt VPC** to use your own network. Everything above the network layer is the same.

| Resource                        | What it does                                                                                          |
| ------------------------------- | ----------------------------------------------------------------------------------------------------- |
| ECS on Fargate                  | Runs the container, with no hosts to patch                                                            |
| Application Load Balancer       | Terminates TLS on your hostname. The only public component, open to the internet unless you narrow it |
| RDS PostgreSQL (platform)       | Application data, with pgvector for knowledge search                                                  |
| RDS PostgreSQL (audit)          | The audit record. Its writer can insert and read, never update or delete                              |
| S3, Secrets Manager, CloudWatch | Large content, every secret, and logs kept 30 days                                                    |
| AWS Budgets                     | Emails at 85% and 100% of a monthly figure. It doesn't cap spend                                      |

You create an ACM certificate for your hostname and an ECR repository beforehand. There's no AWS WAF in the template, encryption uses AWS-managed keys unless you pass your own KMS key, and the databases are single-AZ with seven days of backups.

## What leaves your account

There's no call-home, no license kill switch and no Mindset control plane in the request path. The deployment reaches only destinations you choose: your model providers, OpenAI for embeddings (so private subnets need an internet route), Postmark for invite and reset emails, Google if you turn on Google sign-in, your OpenTelemetry endpoint, and the systems your connections name.

> **Info:** Hosting it yourself changes where Mindset runs, not its rules. Your org's [compliance settings](https://docs.mindset.ai/docs/compliance) and the audit record work the same.

## What you provide

- An AWS account, ideally dedicated, and someone who can provision networking, databases and IAM.
- An ECR repository and a push role. We push signed releases into it, and the role can't delete.
- A hostname and access to its DNS.
- Model provider credentials, plus an OpenAI key for embeddings.
- A Postmark server token or a Google sign-in client. Without one of them, nobody can sign in as the operator.

> **Warning:** One deployment runs in one AWS region, and the Mindset region (`eu` or `us`) is stamped at first boot and can't change.

## Operate it from Backstage

Every deployment has one reserved org, **Backstage**. Its admins are platform operators and see two more tabs in **Settings**: **Instance keys** and **Platform**.

### 1. Name the first operator

During the install, run `migrate-db.sh --stack-name <name> --admin-email <operator email>`. Leave `--admin-email` out on upgrades.

### 2. Sign in to Backstage

Go straight to `https://<your host>/backstage` and sign in with an emailed link or Google. The org chooser never offers it.

### 3. Provision the instance key

**Settings → Instance keys → Provision** sets one model key for the whole deployment. Orgs without their own key, and the built-in agents, run on it. Without it they're refused with `runtime_not_configured`.

### 4. Create the first org

**Settings → Platform → New organization** creates an org and invites its first admin, who then [rolls it out](https://docs.mindset.ai/docs/roll-out-mindset).

**Platform** lists every org. **Invite admin**, **Suspend**, **Restore** and **Purge** are recorded in that org's own audit trail, naming you. **Purge** erases the org from every store and can't be undone.

```
List the orgs on this deployment, then limit the finance org to 5 runs in flight and 60 new conversations a minute through the public API.
```

Those two figures are the default admission limits. There's no screen for them: an operator sets them through the `mindset-admin` MCP server, per org, agent or function.

## Keep it current

We push each release into your registry, and you decide when to apply it. Nothing upgrades itself. A release carries the image, a signed manifest, a signed SBOM and its own template pack.

The upgrade is ten scripts in the pack's upgrade guide, from any shipped release to the latest in one pass: read the release, pin the install family, plan the migration, **snapshot both databases**, migrate, deploy, smoke check (exit `3` is expected), backfill, smoke check again (exit `0`), and revert the pin.

An upgrade can split shared scripts into per-agent copies, add versions to agent history, fill in availability and retire schedules on deleted agents. Crossing release 1.6.26 causes a short outage while the health check moves, so take it in a quiet period.

## What can go wrong

- **Rolling back means restoring both databases** from the upgrade's snapshots. Deploying an older image doesn't undo a migration. Do it with your Mindset contact.
- **Uptime is yours, and we can't see your deployment.** When we help diagnose, we ask you for logs.
- **Uninstalling leaves secrets behind** (`conn-…` and `inst-…`), live and billed. The uninstall script deletes them only with `--delete-runtime-secrets`.
- **Function runs share the serving tasks,** so size for your combined peak.

## Done when

- The stack is deployed, the smoke check exits `0`, and an operator can sign in to Backstage.
- An instance key is set, and the first org's admin has accepted their invite.
- You've read the upgrade guide before the first release arrives.
