Version. 0.2 Date. 2026-05-07 Provenance. Claude.ai scoping session. Operator: Marvin Percival. Status. Discovery-stage deployment architecture. Four production instances across three providers, plus a public marketing website. Cost and revenue projections. Fleet management mechanics via DevOps engagements.
Prior versions and what changed.
credit schema. Replaces the separate "credit store DB" line item on every instance. Driven by trigger atomicity, transactional signup, and operational simplicity. Per-instance credit schema for local operations (flows, balances, oracle, claimed grants).Additionally: fleet management mechanics carried forward unchanged. Test sequence updated for grant flow. Cost projections adjusted for co-located credit schema (slight reduction per instance).
Four production instances plus a public marketing website. Each production instance is a complete Loomworks deployment (engine + Operator Layer + database with credit schema). Each is managed as a DevOps engagement on DUNIN7's own Loomworks — the control plane instance.
Public marketing website (loomworks.com)
└── Credit request form → posts to Instance A's Authority
DUNIN7 HQ Loomworks (Instance A — the control plane and Authority)
├── DevOps Engagement: Instance A (DUNIN7 internal)
├── DevOps Engagement: Instance B (US production)
├── DevOps Engagement: Instance C (EU production)
├── DevOps Engagement: Instance D (APAC / white-label)
├── Credit Management Engagement (the Authority — issues all grants, owns email registry)
├── Accounting Engagement (Instance A's local balances)
└── DUNIN7's own operational engagements (Loomworks-the-product, FarmGuard, etc.)
Instance B / Instance C / Instance D (production)
├── Engine + Operator Layer
├── credit schema (local flows, local balances, local oracle, claimed grants)
└── Accounting Engagement (this instance's local balances, maintained by trigger)
The Authority is Instance A. Each production instance runs its own credit schema for local operational data. The email registry is single-source on Instance A — abuse boundary preserved across the fleet.
Purpose: DUNIN7's own Loomworks. Development, testing, fleet management, the Credits Authority (Credit Management Engagement holds the email registry and issues grants for the entire fleet), Instance A's own Accounting Engagement, operational engagements (Loomworks-the-product, Enrollium, ExpenseDesk, FarmGuard). The control plane.
Provider: Hetzner CPX22 (Frankfurt) Spec: 2 vCPU AMD, 4GB RAM, 80GB NVMe, 20TB transfer Jurisdiction: Germany (GDPR-compliant, EU data residency)
| Component | What runs |
|-----------|----------|
| Engine | FastAPI, all background workers, SSE |
| Operator Layer | Next.js on port 3001 |
| Engine DB | PostgreSQL with public (engine) and credit schemas |
| Authority surfaces | Grant issuance, email registry, cross-instance grant lookup endpoints |
| File storage | Local NVMe (80GB) |
| Reverse proxy | Nginx + Let's Encrypt SSL |
Users: 1–3 (Marvin + collaborators) for the local Loomworks. The Authority surfaces serve every instance in the fleet. Low traffic on the local product; moderate on the Authority endpoints (grant issuance + eligibility checks).
Monthly cost:
| Item | Cost | |------|------| | Hetzner CPX22 | €7.99 (~$8.70) | | Domain + DNS | ~$1.00 | | Total | ~$10/month |
Revenue: $0 direct. This instance's value is fleet management, the Authority, and DUNIN7's own engagements.
Purpose: Primary US-facing production instance. Trial users (claim grants here), Maker, Professional, Team tiers. The first instance that serves paying customers.
Provider: Railway Pro Region: US-West (Railway's default) or US-East when available Jurisdiction: United States (no specific regulatory framework beyond standard US law; liberal jurisdiction for general-purpose use)
| Component | Spec | Monthly cost |
|-----------|------|-------------|
| Engine | 1 vCPU, 1GB RAM | ~$15–20 |
| Operator Layer | 0.5 vCPU, 512MB RAM | ~$7–10 |
| Engine DB (with credit schema) | PostgreSQL 1GB RAM, 12GB storage | ~$10–15 |
| Infrastructure total | | ~$32–45/month |
The credit schema lives in the same engine database. Slight storage increase over a credit-data-free engine DB (~12GB vs 10GB allowance), but no separate database costs.
Projected users (first 6 months):
| Month | Trial | Maker ($0) | Professional ($29) | Team ($19/seat) | Total users | |-------|-------|-----------|-------------------|----------------|------------| | 1 | 10 | 0 | 0 | 0 | 10 | | 2 | 15 | 3 | 1 | 0 | 19 | | 3 | 20 | 5 | 3 | 0 | 28 | | 4 | 25 | 8 | 5 | 1 team (3 seats) | 41 | | 5 | 30 | 10 | 8 | 2 teams (6 seats) | 54 | | 6 | 30 | 12 | 12 | 3 teams (9 seats) | 63 |
Revenue projection (months 1–6):
| Month | Professional | Team | Monthly revenue | Cumulative | |-------|-------------|------|----------------|-----------| | 1 | $0 | $0 | $0 | $0 | | 2 | $29 | $0 | $29 | $29 | | 3 | $87 | $0 | $87 | $116 | | 4 | $145 | $57 | $202 | $318 | | 5 | $232 | $114 | $346 | $664 | | 6 | $348 | $171 | $519 | $1,183 |
LLM cost exposure (system key for trial users — Haiku responder per credit scoping v0.6 §3.4):
Assumptions: ~10 conversation turns per trial user per month. ~6,000 tokens per turn (input + output). Haiku 4.5 pricing: ~$0.001/1K input, ~$0.005/1K output.
| Month | Trial users | Turns | Est. LLM cost (Haiku) | |-------|------------|-------|----------------------| | 1 | 10 | 100 | ~$1.50 | | 2 | 15 | 150 | ~$2.25 | | 3 | 20 | 200 | ~$3.00 | | 6 | 30 | 300 | ~$4.50 |
The Haiku model selection for trial users dramatically reduces LLM cost exposure compared to v0.1's Sonnet assumption (~$15/month at month 6 became ~$4.50). This makes trial scaling much cheaper.
Monthly P&L at month 6:
| | Amount | |--|--------| | Revenue (Professional + Team) | $519 | | Infrastructure | -$45 | | Trial LLM cost (Haiku, system key) | -$5 | | Net | ~$469/month |
Purpose: EU-facing production instance. GDPR-compliant data residency. Serves European Operators who require or prefer EU jurisdiction.
Provider: Hetzner CPX32 (Frankfurt) + Coolify (open-source PaaS) Spec: 4 vCPU AMD, 8GB RAM, 160GB NVMe, 20TB transfer Jurisdiction: Germany (GDPR, EU data residency guaranteed, Schrems II compliant)
| Item | Monthly cost | |------|-------------| | Hetzner CPX32 | €15.59 (~$17.00) | | Coolify (self-hosted, free) | $0 | | Domain + DNS | ~$1.00 | | Automated backups (Hetzner) | ~$3.00 | | Infrastructure total | ~$21/month |
The credit schema lives in Instance C's engine database. Local flows, local balances, local Accounting Engagement. Eligibility checks at grant issuance time go to Instance A (hash lookup over HTTP), but no PII crosses borders — only SHA-256 hashes.
Why Hetzner for EU: Cheapest GDPR-compliant option by a wide margin. German company, German data centers, German law. No US subpoena risk (unlike AWS Frankfurt, which is a US company operating in Germany). For Operators who care about data sovereignty, this is the strongest jurisdictional position available at this price point.
Projected users (first 6 months): Slower growth than US — EU adoption is invitation-driven, regulatory trust builds slowly.
| Month | Trial | Maker | Professional | Team | Total | |-------|-------|-------|-------------|------|-------| | 1 | 5 | 0 | 0 | 0 | 5 | | 3 | 10 | 3 | 2 | 0 | 15 | | 6 | 15 | 5 | 5 | 1 team (3) | 28 |
Revenue at month 6: ~$202/month (5 Professional + 1 Team) Infrastructure: ~$21/month Trial LLM cost (Haiku): ~$2/month Net at month 6: ~$179/month
Purpose: First managed-hosting or white-label instance. Spun up when a partner or enterprise customer requests dedicated infrastructure.
Provider: AWS (us-east-1 or eu-west-1, customer's choice) Jurisdiction: Customer-determined
| Item | Monthly cost |
|------|-------------|
| ECS Fargate (engine + frontend) | ~$20–30 |
| RDS PostgreSQL (engine DB with credit schema) | ~$30 |
| ALB | ~$16 |
| S3 | ~$1 |
| Infrastructure total | ~$67–77/month |
Single PostgreSQL instance handles both the engine schema and the credit schema. Slight storage overhead from co-located credit data; no separate RDS instance needed.
Revenue model: The customer pays a managed-hosting fee that covers infrastructure + margin. Proposed: $199–499/month depending on scale, plus per-seat license fees for their users. DUNIN7 manages the instance through the DevOps engagement on Instance A. The customer never touches infrastructure.
Trigger: Instance D is not pre-deployed. It's created when demand justifies it.
Purpose: Public face of Loomworks. Introduces the product, explains engagement memory and the agentic-era thesis, hosts the credit request form (the form-initiated grant flow per credit scoping v0.7 §8). The form is the primary acquisition surface.
Provider: Cloudflare Pages or Netlify or Vercel (any static-site host with form/API support) Region: Global CDN (edge-cached) Jurisdiction: Server-side requests (form submissions) hit Instance A's Authority — Authority's jurisdiction (Germany) governs PII handling.
| Component | Cost | |-----------|------| | Static hosting (Cloudflare Pages or similar) | $0 (free tier sufficient for early traffic) | | Domain (loomworks.com) | ~$1/month amortized | | Form submission posting to Instance A | $0 (the website is a thin form; Instance A handles submission processing) | | Infrastructure total | ~$1/month |
What the website is:
POST /authority/grant-request endpointBuild effort: Modest (a few days at alpha). Can start as a single landing page with form, expand later. The brand guide and DESIGN.md tokens already exist; the website should use them for visual continuity with the product.
Where it sits in the sequence: Phase 47 doesn't require the website (the alpha grant flow uses Operator-curated grants via the admin endpoint, no public form). Phase 48 needs the form endpoint on Instance A. The website can ship anywhere from "with Phase 48" to "after Phase 48 alongside instance B going live publicly." Practically: build it once Phase 47 has tagged and Phase 48 is in flight.
| Item | Provider | Monthly cost | Monthly revenue (month 6) | Net | |------|---------|-------------|--------------------------|-----| | Marketing website | Cloudflare Pages | $1 | $0 | -$1 | | A (DUNIN7 internal + Authority) | Hetzner | $10 | $0 (management + Authority) | -$10 | | B (US production) | Railway | $45 | $519 | +$474 | | C (EU production) | Hetzner | $21 | $202 | +$181 | | D (managed, if active) | AWS | $77 | $199–499 | +$122–422 | | Fleet total | | $77–154 | $721–1,220 | +$644–1,066 |
Break-even point: 3 Professional subscribers across the fleet cover all infrastructure costs (slightly improved over v0.1 because of credit schema co-location reducing per-instance DB costs).
The marketing website cost is rounding error; the LLM cost reduction from Haiku (~$15/month → ~$5/month at scale) is the larger improvement in unit economics.
Carried forward from v0.1 with adjustments for the two-engagement model.
DUNIN7's Companion on Instance A has cross-engagement awareness across all DevOps engagements, the Credit Management Engagement (Authority), and Instance A's own Accounting Engagement. Each DevOps engagement's Memory contains:
The Credit Management Engagement's Memory contains:
campaign_refInstance A's Accounting Engagement contains Instance A's own balance state and reconciliation history. Each production instance has its own Accounting Engagement maintained locally, and the Companion can query each via cross-instance HTTP for fleet-aggregate questions.
The Companion can answer fleet-level questions:
Carried forward from v0.1 unchanged. The deployment specification, approval card, FORAY attestation pattern works regardless of the credit data location.
Same table as v0.1, with one addition:
| Operation | Trigger | DevOps engagement action | |-----------|---------|------------------------| | Deploy new build | Operator request or new tag | Shape → Approve → Render (deploy) | | Scale up/down | Health alert or observation | Shape → Approve → Render (scale) | | Provision new instance | Customer request or fleet decision | Shape → Approve → Render (provision) | | Decommission instance | Business decision | Shape → Approve → Render (teardown) | | Rotate secrets | Scheduled or incident | Shape → Approve → Render (rotate) | | Database backup | Scheduled | Automatic | | SSL renewal | Approaching expiry | Automatic or approval-gated | | Incident response | Health alert | Companion surfaces alert, proposes action | | Cost optimization | Monthly review | Companion analyzes spend, proposes changes | | Authority-side alert (NEW) | Email registry signals (e.g., spike in INELIGIBLE results) | Credit Management Engagement surfaces, Operator decides response |
The Operator's morning routine:
The fleet management surface is the Companion. Same Companion that manages Loomworks-the-product also manages the fleet, the Authority, and the financial picture.
credit schema with its own flows, balances, oracle, and claimed grants. The Accounting Engagement's trigger fires on local insert; the trigger evaluator runs locally.The form-initiated grant flow that crosses instances:
Marketing website Authority (Instance A) Production instance (B/C)
───────────────── ────────────────────── ─────────────────────────
Form submission ────────► POST /authority/grant-request
(questions, email) │
▼
check_email_eligibility(email)
(registry lookup, hash both forms)
│
▼
Companion-as-Authority decides:
- credit type (haiku/sonnet/opus)
- amount
- destination instance (based on jurisdiction question, geography, etc.)
│
▼
issue_grant(...) writes credit_grant row
generates claim_token
registers email hash
│
▼
send email with claim link to:
https://[destination-instance]/claim?token=<claim_token>
│
▼
(recipient receives email)
│
▼
recipient clicks link ────────► claim endpoint receives token
│
▼
POST to Instance A:
/authority/grants/{token}/finalize-claim
(verifies token, marks claimed)
│
◄──────── grant details returned
│
▼
Email verification (magic link or passkey)
Create person record on this instance
Write credit issuance flow to local `credit` schema
Trigger fires, local balance row created
│
▼
Recipient lands on Companion with credits loaded
The grant lives on Instance A (Authority) until claim. After claim, the credit issuance flow is written locally on the destination instance, the local trigger updates the local balance, and the user's credits are operationally local. Instance A retains the grant record (now status=claimed, with destination_instance recorded) for fleet observability and abuse forensics.
| Operation | Crosses instances? | Latency budget | |-----------|-------------------|---------------| | Local turn (system key) → balance check | No (local PK lookup) | <1ms | | Local turn → consumption recording | No (local flow write) | <5ms | | Grant issuance | Yes (form → Instance A) | <500ms (acceptable for HTTP-based form) | | Eligibility check | Yes (Instance A's registry) | <100ms | | Claim finalization | Yes (claim instance → Instance A) | <500ms (one-time, at signup) | | Fleet visibility queries | Yes (Companion → all instances) | Background, not user-facing |
The hot path (local converse turn) does NOT cross instances. This is the operational resilience benefit of per-instance credit schema. Instance A going down doesn't stop existing users' Companion turns on Instance B; it only stops new grant issuance.
This is a meaningful resilience improvement over a centralized credit store. Authority outage degrades acquisition; it doesn't degrade existing user experience.
To stand up the full fleet plus the marketing website and verify everything works:
One-time setup costs:
| Item | Cost | |------|------| | Marketing website hosting (Cloudflare Pages) + domain | ~$15 | | Hetzner Instance A (1 month) | $10 | | Railway Instance B (1 month) | $45 | | Hetzner Instance C (1 month) | $21 | | AWS Instance D (1 month, if testing managed) | $77 | | Domain registrations (3–4 production domains) | ~$40 | | Anthropic API credit for system key (Haiku trial users) | $10 | | Total first month | ~$141–218 |
Ongoing monthly if all four instances + website stay active: ~$77–154 (without AWS Instance D: ~$77).
Skip Instance D. Stand up website + A + B + C:
| Item | Provider | Monthly cost | |------|---------|-------------| | Marketing website | Cloudflare Pages | $1 | | A (DUNIN7 HQ + Authority) | Hetzner CPX22 | $10 | | B (US production) | Railway Pro | $45 | | C (EU production) | Hetzner CPX32 | $21 | | Total | | ~$77/month |
Plus ~$10 in Anthropic credits for trial testing (Haiku rates make this much cheaper than v0.1's $20). Total test cost: ~$87 for the first month.
email+plus-suffix@domain.com variant → INELIGIBLE_RECENT (normalization catches it)The marketing website is the new entry point; the test sequence starts with verifying the website-to-Authority round trip rather than directly creating invitation codes via admin endpoint as v0.1 had it.
Carrying forward from §2 with a few notes the v0.1 didn't address.
The website's content is editorial and the form is a simple POST. Whatever stack ships fastest while looking good. No backend logic on the website itself — the form posts directly to Instance A's Authority endpoint over HTTPS.
A few days for a single-page site with form. Can ship before Phase 48 is complete (form endpoint on Instance A is what blocks). Practical sequence:
The form may need a question to determine which production instance the user lands on. Or the Authority could decide based on geography (IP-based, user-stated, or asked at form). This affects whether EU users land on Instance C (preferred for them) or Instance B (default for now).
The simplest approach for early alpha: one question on the form ("Where are you based?") drives the destination instance. Refinements later.
Phase 47 alpha has no SMTP. The Authority generates the claim URL but the Operator manually delivers the email (copy-paste from admin endpoint output, or via the Companion). Phase 48 ships SMTP. The website-to-Authority flow doesn't need SMTP at all (Authority just stores the grant); only the recipient-notification step needs SMTP.
The Companion on Instance A queries each instance's local Accounting Engagement for fleet-wide questions. This is HTTP cross-instance traffic, but it's background — not user-facing. Cache + 5-minute refresh is probably fine for "what's the fleet state right now?" queries.
The marketing website hosted on Cloudflare Pages with no cookies (static + form post) is the simplest GDPR posture. No cookie banner needed if no cookies are set. Form submission discloses email; that's covered by the privacy policy.
DUNIN7 — Done In Seven LLC — Miami, Florida Multi-instance deployment strategy — v0.2 — 2026-05-07