Chapter 27 — Environments & Sandboxes
Attend onboarding guide · ~7 min read · ↑ Back to contents
You know the machinery; now, where does it run? This chapter covers the environments the code lives in, and — more interesting — how the vendor side of dev/prod works, because the vendors draw that line in three completely different ways.
Where things deploy
| Layer | Where | Notes |
|---|---|---|
| Backends (flex-v3, cortex, flow…) | Porter → AWS | builds, deploys, and environment variables all managed in Porter |
| New frontends (Flex, Premium, Cortex, Flow v3) | Vercel | env vars per project |
| Older frontends + dev sites for new ones | Netlify | legacy products live here |
| Database | one shared dev RDS + production RDS | see below |
The thing that surprises everyone: there is no per-developer database. Your local backend, the deployed dev backend, and every teammate's laptop all point at the same dev RDS — same clients, same schemas, same data. That's a feature: anyone can inspect anyone's setup, and Cortex/Flex/Flow all see one consistent world. The team browses it with DBeaver (credentials travel with the env files; host and username are fixed, only the password is secret).
The flip side: a careless write on "your" local affects the shared dev world. Schemas keep tenants
isolated, but be deliberate inside the dashboard tables (tbl_clients, tbl_client_schema,
tbl_users_schema_mapping) that everything reads.
How each vendor does "sandbox"
Recall from Chapter 25 that TM is really two systems. They diverge again on environments:
TM Archtics — sandbox is a fake team
Archtics splits the world into per-team DSNs (each team = its own TM property, config, and
database). The APIs are identical everywhere — what makes a team config "sandbox" is just four
values: dsn, siteName, clientId, integratorId. Point them at the TM-created fake team
(dsn: 'sandbox', siteName: 'integ3') and you're in a playground where the events are fake,
payments are controlled, and nothing real can break. Swap in a real team's four values and the
same code talks to production.
Sandbox inventory is the famous SS1–SS15 event-code series. It is somewhat hacky and not entirely reliable — SS1 has quietly drifted into the past and broken transactions until someone noticed. If a sandbox flow fails mysteriously, check the event dates before blaming your code.
TM Host — sandbox is a URL infix
Host has no team separation at all — no DSN, one shared API key, everything interlinked (one
request can return Sharks, Jaguars, and Iowa State events together). So there's nothing config-ish
to swap. Instead, the environment is chosen by the API URL: the normal URL hits production;
add the preprod infix and the same call hits their sandbox (real Eagles-at-Sphere events
become "Monster Jam by Justin Z" test data). The team config records the team's tmHostEnvironment
(preprod | production) — note urlType is TDC's field, not Host's.
One more Host quirk: since Host has no per-team identity, Host teams reuse the Archtics OAuth flow for fan login — there is no separate "Host auth".
Everything else
TDC and other vendors follow the Archtics pattern: the team config declares "real team X" or "sandbox", with whatever per-vendor properties that takes. The config file is the environment switch — that's why onboarding a team is a code change (see How to onboard a new team).
Sandbox test data cheat-sheet
| What | Value |
|---|---|
| Events (Archtics sandbox) | codes SS1–SS15 |
| Card that succeeds | 4444 3333 2222 1111 |
| Card that fails | 4242 4242 4242 4242 — yes, the Stripe success card; here it's the designated failure card |
| CVV | 111 (use 123 to trigger the error path) |
| Expiry / address / zip | any future date, any US address, any 5-digit zip |
| Phone numbers | US/Canada only — TM is international but Attend normalizes to +1; the frontend enforces E.164. Use any 10-digit US number |
| Purchase emails | dev notifications are real — half the dev team gets your sandbox receipts (timestamps in UTC) |
When TM auth won't cooperate: bypass auth
TM occasionally blocks token extraction from local machines. For that, flex-v3-backend has a
dev-only bypass: set BYPASS_AUTH_ENABLED=true plus BYPASS_EMAIL and BYPASS_ACCOUNT_ID
in the env, and the backend treats you as that fan without a real TM round-trip. The account ID
is per-DSN — the same fan has a different ID in every DSN, so when you switch teams, switch the
ID too (the shared env file keeps a commented list).
Recap
- Porter (backends) + Vercel/Netlify (frontends), all on AWS; env vars live in those dashboards.
- One shared dev RDS for everyone — local dev included. Convenient and communal; be deliberate.
- Archtics sandbox = a fake team (4 config values,
integ3); Host sandbox = a URL infix (preprod); other vendors follow the Archtics pattern. The team config is the switch. - SS1–SS15 events,
4444…succeeds /4242…fails, US phone numbers only. BYPASS_AUTH_ENABLEDskips TM login on dev; account ID is per-DSN.