Forge — our flagship product, built on SC

The Forge stack on SC, in one picture

forge (repo) — parent stack `forge/infra`
   ↓ provisioner: AWS · state bucket: sc-simple-forge-state · DNS zones: simple-forge.com (Forge services + product site) + simple-container.com (this site)
   │
   ├── forge-aigateway     ← Lambda · ai.simple-forge.com
   ├── forge-conductor     ← Lambda · app.simple-forge.com
   ├── forge-sessions      ← Lambda · sessions.simple-forge.com
   ├── forge-runtime       ← Fargate workers + ECR for VM-based agents
   ├── simple-forge.com    ← S3 + CloudFront (the Forge product site)
   └── simple-container.com← S3 + CloudFront (this site)

Every box above is a separate repository with its own .sc/stacks/<name>/client.yaml that references parent: forge/infra. The parent is checked out by SC at deploy time via the parentRepository config in each child’s .sc/cfg.github.yaml.

What you get if you adopt the same pattern

• One source of truth for shared infra — one parent stack defines your DB, queue, registries, DNS, ACM certs. New services don’t reprovision them.
• Cross-repo deployments stay sane — parent stack in one place; child stacks live with the code they describe.
• State is segregated — each child stack has its own Pulumi state. Roll back one without touching others.
• CI is one workflow per stack — sc cicd generate -s <stack> produces the GitHub Actions YAML; you commit and forget.
• Receipts on every deploy — sc release runs scan + sign + SBOM + provenance as part of the pipeline.

Why Forge needed Simple Container

When we started Forge, we asked the same question every multi-agent platform asks: how do AI agents touch real production infrastructure safely? Multi-step agentic workflows on real customer accounts is a security minefield — secrets, deploy access, rollback authority, audit trail, all of it.

SC answered the substrate question: encrypted-in-git secrets, deterministic Pulumi-backed deploys, per-service IAM, the whole sc release supply-chain pipeline. Forge wraps SC with the AI orchestration on top: multi-persona workflows, manager validation per handoff, git as the audit trail. The combination is what actually delivers 0-to-prod.

If you want to read the long version, the blog post walks through it.

Three layers, and who sees which

The stack above has grown a third floor, and it is the one that makes the other two worth building.

• Simple Container deploys it. Every box in the diagram, plus the ones that came after — one parent stack, encrypted secrets, a state bucket, sc release on every push.
• Forge runs it. Agent workflows, the LLM gateway, sessions, the runtime that executes turns. This is the machinery, and it is addressed by engineers.
• Atrium is the builder on top. Forge is the platform underneath; Atrium is the CMS-shaped tool a company creates and manages its portal in. It describes what its customers should be able to do, and the portal is composed from parts that already run — accounts, an assistant that acts, background jobs, a per-customer cost line — then opens on that company’s own domain. The portal is what a customer touches; Atrium is where it gets built.

The interesting property is the seam between the second and third floors. Nothing from the Forge layer reaches a portal user — not an identifier, not a hostname, not a line of an error message — and that is held by an import-graph rule and a response scan rather than by a style guide. It is the same discipline SC applies to secrets, pointed at vocabulary instead.

For this site the point is narrower: a three-floor product, six service repos and two marketing sites all deploy from one parent stack, and the config that does it is the same config in this documentation.

Read more

• Forge product site — what Forge does
• Forge — workflow engine — the engine architecture
• How Forge handles secrets safely — the SC primitives underneath
• Atrium — the builder for the portals customers actually touch