ARCHE
FamiliesLive demoDocsExamplesBlogGitHub ↗
Documentation

Start

  • Getting started
  • Philosophy

Guides

  • First hour
  • Agent context
  • Verification
  • Package managers
  • Scaffold lifecycle
  • Showcase & portfolio

Walkthroughs

  • TypeScript fullstack
  • Convex product
  • Rust API & fullstack
  • Solana family
  • Customize & experiments
  • Automation (JSON/MCP)

CLI

  • Overview
  • Flags
  • Subcommands
  • Generated output

Presets

  • Preset catalog

Stack

  • TypeScript architecture
  • Convex
  • Rust
  • Solana
  • Authentication
  • Prisma store
  • tRPC

Operations

  • Deployment
  • Environment variables
  • Workers & queues
  • CI & testing
  • Scaling
  • Security
  • Troubleshooting

Reference

  • Stack links
  • Capabilities
  • This source repo
  • Code examples
← Documentation

Security

Validation, secrets, and defaults in generated TypeScript projects.

1 min read

Security here means baseline hygiene the scaffold encodes—not a certification.

Loading diagram…

Input and API

  • tRPC procedures use Zod (or shared validators) at boundaries
  • Prefer policy checks for authorization—not “security by obscurity” routes
  • Keep server-only code out of client bundles via package exports

Secrets and env

  • .env.example lists required keys; serverEnv validates at boot in packages/backend-common
  • Never commit .env with production secrets
  • Rotate BETTER_AUTH_SECRET if leaked

Transport

  • Production: HTTPS everywhere; align FRONTEND_URL and BETTER_AUTH_URL with real origins
  • CORS is configured on the API for the web origin—update when adding staging domains

Dependencies

  • Run your package manager’s audit in CI (bun run ci includes lint/typecheck; add audit if your team requires it)
  • Pin catalogs via workspace catalog files when using Bun/pnpm

Agents

Generated repos include agent maps—not extra attack surface, but do not paste production secrets into agent chats. Use .env locally and platform secret stores in deploy hosts.

Reporting

This is a personal/template project. For production apps you ship, follow your own disclosure process.

Demo endpoints (/live)

The live sandbox (proof run, chat, posts) is intentionally public for evaluation. Treat it as demo-only.

ProcedureAuthPublic dataNotes
helloNoGreeting stringHarmless contract check
post.listNoPublished posts onlyDrafts filtered server-side
post.createYes—Draft only; max title/content lengths
chat.listNoMessages + redacted sender (id, name, image)No email in JSON
chat.statsNoMessage count + latest timestampActivity strip metadata
chat.sendYes—Max 280 chars; visible to all readers
GET /api/chat/streamNoSSE message eventsHeartbeat every 30s; rate limited
auth.getSessionNoSession user or nullNo secrets
auth.getSecretMessageYesProtected stringProof-run only
user.findUserByEmailYesSelf email onlyReturns public user shape

SSE: One-way push from the API after chat.send. Clients invalidate chat.list on events; polling is the fallback when the stream drops (e.g. cold starts).

Before production: remove /live, demo auth pages, and seed chat messages—or restrict these procedures behind admin policy. Run template-cleanup --remove=live on generated projects.

On this page

  • Input and API
  • Secrets and env
  • Transport
  • Dependencies
  • Agents
  • Reporting
  • Demo endpoints (/live)