The Pattern Repeats: palmer-ai Live in Under Ten Minutes

Why Care?

A pattern you've executed once is an anecdote; twice from the written procedure is a pattern. Hours after reach-edu went live, palmer-ai got the identical stack — deployed from docs/twenty/setup.md rather than from memory, which was the whole point: every divergence would have been a pattern bug. There were essentially none.

What's New?

• palmer-ai Railway project: same five resources (twenty-server, twenty-worker, twenty-postgres, twenty-redis, twenty-storage bucket), same pinned image twentycrm/twenty:v2.24.1, own database, nothing shared with reach-edu (D2 holds).

• Zero failed deploys — the PORT healthcheck lesson from reach-edu was pre-applied; the server passed its first healthcheck.

• Reference variables from birth — the postgres password has one source of truth and the canvas shows the dependency graph immediately.

• Four real companies written through the API and read back: Reach Capital, New Markets Venture Partners, Kalos Ventures, Juvo Ventures.

• Full artifact parity with reach-edu: .env recovery copy, restore-runbook, mcp-connector.md (OAuth challenge verified live on this instance too), and its own twenty-interface agent skill with an instance-specific OpenAPI snapshot.

The delta list (the actual Phase 2 deliverable)

1. PORT=3000 included in the initial variable set → no healthcheck failure. Runbook fix confirmed effective.

2. Reference-variable wiring moved from "retrofit" to "from birth."

3. railway link --team is deprecated → --workspace (cosmetic).

4. Everything else transferred verbatim. Deploy wall-clock: ~4 minutes of operator time, ~2 minutes of boot.

What's Next

Backups with a restore drill (Phase 3), then the first terminal-poor stakeholder onboarded through the OAuth connector path (Phase 4). The runbook is now two-for-two and starts to smell like the seed of the public FullStackVC guide.