gigamcp/ docs

Silo deployment

Some customers — typically banks, healthcare, defence — have contractual or regulatory requirements that forbid sharing AWS accounts with other tenants. The silo plan tier provisions a dedicated AWS sub-account with its own RDS, OpenSearch Serverless, ECS service, ALB, and KMS key for a single workspace.

What you get

  • Dedicated RDS Postgres instance — no shared database, no row-level security cohabitation.
  • Dedicated OpenSearch Serverless collection for the vector index.
  • Dedicated ECS Fargate service running the gigamcp API + MCP server containers.
  • Dedicated ALB with your custom domain and a customer-managed KMS key.
  • A cross-account IAM role giving the gigamcp on-call team read-only access (CloudWatch logs + describe APIs) so we can support you. No write access without your explicit approval.

What it does NOT change

  • The control plane (signup, billing, identity broker) still runs in our shared account. Silo isolates the data plane.
  • The product surface is identical — same UI, same MCP server, same connectors. Migrations and feature releases ship to the silo on the same cadence as shared.
  • Auth (WorkOS) is still our identity broker; the silo does not change the SSO setup steps.

Cost & pricing

Silo carries a fixed AWS infrastructure premium plus a managed-service fee. Talk to your CSM for current numbers; the AWS bill alone runs ~ $1.5k–4k / month depending on active-user count. We charge a single all-in monthly fee.

Process

  1. Sign the silo addendum to your MSA.
  2. Send us your preferred AWS region (eu-west-1, eu-central-1, us-east-1 supported by default; other regions on request).
  3. Our SRE team:
    1. Bootstraps a new AWS sub-account under the gigamcp organisation.
    2. Applies the silo-tenant Terraform module (~25 minutes for first apply).
    3. Migrates your data from the shared pool using scripts/silo-data-migration.sh — about 60 minutes of read-only maintenance window for a typical 10-GB Postgres.
    4. Cuts the custom domain DNS over to the silo ALB (5 minutes propagation).
    5. Flips your tenant's deployment_tier column from shared to silo; from this point all reads / writes hit the silo.
  4. Verification window — we run smoke tests on the new deployment and you confirm the data parity sample. Total downtime: usually under 90 minutes.

Operations runbook

Internal-only. See docs/15-SILO-UPGRADE.mdin the gigamcp repo for the full procedure including rollback steps. Customers don't need to read this; it's the SRE's reference.

Audit + observability

  • CloudWatch logs + metrics live in your sub-account. We publish to your account and forward a copy to our central observability stack via cross-account read.
  • The audit-stream feature continues to work; events from a silo deployment are tagged with deploymentTier: silo for downstream filtering.

Rollback

Silo migrations are reversible up to 7 days post-cutover; we keep a paused replica of the shared-pool snapshot for that window. After 7 days the shared rows are purged. Talk to your CSM before T+7 if you need to roll back.