Cloudflare Workers
Deploy tripplan.ing to Cloudflare Workers with D1, KV, and R2 for a globally distributed production environment.
Prerequisites
- Cloudflare account with Workers, D1, KV, and R2 enabled
wranglerCLI installed (npm install -g wrangler)- GitHub repository with Actions enabled
Cloudflare resources
A single Worker serves all events. Resources are shared — no per-event provisioning:
| Resource | Type | Purpose |
|---|---|---|
| Worker | Cloudflare Worker | SvelteKit application |
| D1 | Database | All platform and event data |
| KV | Key-value store | Sessions, OTP codes |
| R2 | Object storage | Photos, documents |
Event isolation is enforced by event_id scoping in the database, not by separate resources.
Resource configuration
Resources are configured in apps/event-site/wrangler.toml:
name = "tripplan"
compatibility_flags = ["nodejs_compat"]
[[d1_databases]]
binding = "DB"
database_name = "tripplan-db"
database_id = "your-d1-database-id"
[[kv_namespaces]]
binding = "KV"
id = "your-kv-namespace-id"
[[r2_buckets]]
binding = "R2"
bucket_name = "tripplan-storage"The nodejs_compat compatibility flag is required for dependencies that use Node.js built-in modules.
Adapter
tripplan.ing uses @sveltejs/adapter-cloudflare (not the deprecated adapter-cloudflare-workers):
// svelte.config.js
import adapter from '@sveltejs/adapter-cloudflare';
export default {
kit: {
adapter: adapter()
}
};DNS and domains
Each event gets a subdomain (e.g., reunion.tripplan.ing). Configure DNS:
- Add a CNAME or A record pointing the subdomain to your Worker
- The Worker resolves the hostname to an event via
platform_event_domains - Wildcard DNS (
*.tripplan.ing) simplifies multi-event routing
Or use custom domains — add them to platform_event_domains and configure DNS accordingly.
Go-live checklist
Pre-deploy
- [ ]
npm run checkpasses - [ ]
npm testpasses - [ ]
npm run -w @tripplan/event-site build:workerssucceeds - [ ] GitHub Environments configured (see Environment & Secrets)
GitHub Environment setup
- Create
developmentandproductionenvironments in GitHub - Populate with required variables and secrets
- Verify
CF_DEPLOY_API_TOKENhas deploy permissions
Deploy
- Push to
main(or trigger.github/workflows/apps-ci.ymlmanually) - Confirm all CI stages pass: checks, build, migration, secret sync, deploy
Post-deploy validation
Verify each area works:
| Check | How |
|---|---|
| Platform UI | Sign in at /platform as an operator |
| Event creation | Create a test event at /platform/events/create |
| Event homepage | Visit the event's subdomain |
| Auth OTP | Sign in with an allowed email |
| RSVP | Submit and edit a test RSVP |
| Payments | Complete a Stripe test checkout |
| Webhook | Verify payment status updates after checkout |
| Admin | Access /admin on the event subdomain |
| Photos | Upload and view a test photo |
Docs Worker
The docs site has a separate deployment:
- Run
.github/workflows/docs-deploy.yml - Verify docs load at the configured URL
Rollback
If a deployment causes issues:
- Re-deploy the previous known-good git SHA
- Run migration checks to confirm schema compatibility
- If an event is unhealthy, suspend it via the platform UI while investigating
- Record incident details in the platform audit log
Related pages
- Environment & Secrets — all required configuration
- CI/CD Pipeline — deployment workflow details
- Creating Events — event setup after deployment
- Architecture — how the runtime abstraction works