Mindset docs
llms.txt

OperatorsHost it yourself

Updated 27 Oct 2026View as Markdown

Host it yourself

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

MCP serverSDK and APIYour own cloud:AWSGCPAzureor hosted by MindsetMindset platformAgentScriptVersionRunConnectionOperationFunctionWidgetSecurity and complianceone posture · audit trail · personal data redactionBuilderscoding agentOperatorsAI clientor the StudioYour appthe SDKYour serverthe APIThe Huband schedulesBuilderscoding agentOperatorsAI client or the StudioMCP serverYour own cloud:AWSGCPAzureor hosted by MindsetMindset platformAgentScriptFunctionConnectionOperationWidgetVersionRunSecurity and complianceone posture for the org,audit trail and personal data redactionSDK and APIYour appthe SDKYour serverthe APIThe Huband schedules

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.

ResourceWhat it does
ECS on FargateRuns the container, with no hosts to patch
Application Load BalancerTerminates 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, CloudWatchLarge content, every secret, and logs kept 30 days
AWS BudgetsEmails 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.

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.

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.

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.