Bring Your Opinionated Stack

Our deployment harness already runs AWS Fargate, static web, Cloud Foundry and Kubernetes behind one command surface. Your stack can be the next row in that catalog, with your conventions enforced on every application that lands on it, not just documented for one.

Opinions Enforced, Not Just Documented

An agent that writes and ships software is under-constrained by default: language, framework and layout chosen per run, conventions remembered only as well as the last prompt. A stack narrows that search space to constraints the agent can't wander off from, because the constraints that matter are enforced in code, not just written down. Partnering with us means your stack becomes one of those constraints: a target our agent, and our customers' agents, can build on by name, every time.

🎯

Why Your Stack Belongs Here

Three reasons stack owners partner with us

  • Opinions enforced, not just documented: the agent applies your language, framework, layout and conventions on every generated app, instead of improvising its own
  • Every new app can land on your stack: when the agent builds or adopts an application, your stack is a selectable target, not an afterthought
  • Adoption without a sales-engineering queue: developers describe what they want, and the agent does the setup work your docs currently ask them to do by hand
🔌

How Your Stack Plugs In

Three pieces, one contract

Intent: app.yaml

Lives in the application repo. What runs, how big, what it needs, where it answers. Unchanged by your stack.

Your adapter

Resolves that intent into your native form: catalog, render, push, guards. You provide this.

Your profile and skill

Your opinions as data: language, framework, tests, folder layout. You provide this, and it's how the agent learns your conventions.

Intent never contains ARNs, org names, kube contexts or secret values. Those belong to your stack, supplied out of band the same way every stack on the harness already handles secrets.

📜

The Stack Contract: Ten Obligations

What makes something a deployment stack is written down

  • 1. Catalog: list what you deploy and where
  • 2. Read app.yaml unchanged: the application's intent is never edited to fit your stack
  • 3. Build: from a recipe or an image
  • 4. Run: services at the declared size, count and health check
  • 5. Broker: backing services by offering, not by brand name
  • 6. Bind: credentials only to the containers listed
  • 7. Keep secret values out of every repo
  • 8. Route: the colour host always, the live host when live
  • 9. Guard: refuse the wrong account, org or context
  • 10. Preview before acting

Anything your stack cannot do is reported as a problem, never silently dropped.

🪜

The Onboarding Path

Two steps work today; two are where a design partner shapes what's next

1. Register

Add your stack to the estate registry as a deployment stack with an adapter. Works today.

2. Conform

Render and doctor run clean against a reference application, and the problem list is empty. Works today.

3. Encode

Publish your profile and skill so the agent knows your opinions as data, not prose. Roadmap.

4. Prove

The agent builds a reference application on your stack and plans its deploy end to end. Roadmap.

Steps 1 and 2 work with the harness today. Steps 3 and 4 are open work, tracked alongside the rest of our accelerators roadmap — this is where a design partner shapes them rather than waiting for them.

🛡️

Guardrails Your Customers Can Trust

The same guards as every stack on the harness, inherited by yours

Preview before acting

Plan, render and dry-run show what will change before anything does.

Secrets stay out of band

Values never enter a repo or the model's context.

Target guards

The wrong account, org or context is a refusal, not a warning.

Human gate on risk

Mutating actions need approval; destructive ones need a typed confirmation too.

🤝

What You Bring, What We Bring

A partnership with a short list on each side

You bring

Your opinions as language, framework, layout and conventions; an adapter for catalog, render and push on your runtime; a reference application that passes doctor; and a named technical owner.

We bring

An agent and skills that generate to your profile; one command surface for catalog, doctor, render and deploy; guardrails already proven across four stacks; and a path to every application we help build.

Let's Add Your Stack

Share your golden path, name a technical owner, and pick one reference application to build and plan end to end.