OneSummer Infrastructure

The architecture is split into three capability zones: a static CDN edge for the SvelteKit frontend, a serverless/container API tier that scales to zero in the off-season, and a managed database tier with connection pooling to absorb burst traffic during Feb–May.

The SvelteKit frontend compiles to static assets (HTML, CSS, JS) at build time via adapter-static or SSR edge functions. These assets are served from a global CDN with no compute cost per request. This is the most cost-effective option and scales to any traffic level automatically.

Recommended: Netlify

Netlify's free tier covers 100 GB bandwidth and 300 build minutes per month — sufficient for off-season and early growth. Their SvelteKit adapter is well-maintained and build previews per PR are included at no cost.

Alternatives

Seasonal Configuration

• No seasonal tuning required — CDN cost scales linearly with traffic and is effectively zero during low season on free/pro tiers.
• Set aggressive cache headers: Cache-Control: public, max-age=31536000, immutable on hashed assets.
• Enable HTTP/2 and Brotli compression (default on all recommended providers).
• Use _headers / netlify.toml to set X-Frame-Options, Content-Security-Policy, and Permissions-Policy at the CDN edge — zero compute cost.

The API is a Docker container running a standard HTTP server (Fastify, Hono, or similar). The critical requirement is scale-to-zero: during the off-season, the container should cost nothing when idle. This narrows the field to platforms with built-in zero-scaling.

Recommended: Fly.io

Fly.io supports Docker containers with native scale-to-zero via min_machines_running = 0. Machines wake on the first inbound request. The free tier includes 3 shared-CPU VMs and 3 GB storage — enough for the API + background workers.

Alternatives

Container Configuration

# fly.toml — peak season config
[http_service]
  internal_port = 3000
  force_https   = true

  [http_service.concurrency]
    type       = "requests"
    soft_limit = 200   # scale up above this
    hard_limit = 250

[[vm]]
  size               = "shared-cpu-1x"
  memory             = "512mb"

[autoscale]
  min_machines_running = 0   # ← scale to zero off-season
  max_machines_running = 10  # ← burst capacity for Feb–May

Object Storage

Application documents, uploaded profile photos, and camp media are stored in S3-compatible object storage separate from the container. Cloudflare R2 is recommended for zero egress fees. Alternatives: AWS S3 Backblaze B2.

Email Delivery

Transactional emails (application confirmations, parental consent requests, status updates) require a dedicated provider. Resend offers 3,000 free emails/month with React Email template support. Alternative: Postmark.

OneSummer requires a managed PostgreSQL database. The database cannot scale to zero — it must persist all user data year-round — but it can run on a minimal instance during the off-season and scale up for Feb–May. Connection pooling is critical: serverless/container platforms open many short-lived connections; without pooling, Postgres will exhaust its connection limit under modest load.

Recommended: Neon

Neon is a serverless Postgres provider that separates storage from compute. The free tier includes 0.5 GB storage, autoscaling compute, and a built-in connection pooler (PgBouncer). Compute scales to zero after a period of inactivity — during the off-season, the database compute cost approaches zero while data remains durable.

Alternatives

Connection Pooling Architecture

# Application → PgBouncer → Postgres
# Use TRANSACTION mode for serverless/container workloads

DATABASE_URL="postgresql://user:pass@pooler.neon.tech:5432/onesummer?pgbouncer=true"
DATABASE_DIRECT_URL="postgresql://user:pass@ep-xxx.neon.tech:5432/onesummer"
#                  ↑ direct connection for migrations only

# Recommended pool settings (Neon default)
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20   # actual Postgres connections

Migration Strategy

Use Drizzle ORM or Prisma for schema management. Run migrations via the direct (non-pooled) connection URL only. Never run ALTER TABLE through the pooler in transaction mode — it will fail on long-running DDL statements.

Backup Policy

• Neon provides point-in-time recovery (PITR) up to 7 days on free tier, 30 days on Pro.
• Take a manual pg_dump backup before every major migration and store in object storage.
• Set up a daily automated backup job via GitHub Actions cron during peak season.

All deployments flow through GitHub Actions. The pipeline enforces test passage, security scanning, and preview deployment before any changes reach production.

GitHub Actions Workflow Structure

# .github/workflows/
ci.yml           # runs on every PR
  ├─ lint (eslint + prettier)
  ├─ type-check (tsc --noEmit)
  ├─ unit tests (vitest)
  ├─ integration tests (against Neon branch)
  └─ security scan (npm audit + semgrep)

preview.yml      # runs on PR open/update
  ├─ build Docker image
  ├─ deploy API to Fly.io preview app
  ├─ deploy frontend to Netlify draft URL
  └─ create/update Neon DB branch

deploy.yml       # runs on merge to main
  ├─ build + push Docker image to registry
  ├─ run database migrations (direct URL)
  ├─ deploy to Fly.io production
  ├─ deploy frontend to Netlify production
  └─ post-deploy smoke tests

backup.yml       # cron: 0 2 * * * (2am daily, peak season)
  └─ pg_dump → compress → upload to R2

Container Registry

Push Docker images to GitHub Container Registry (ghcr.io) — free for public repos, $0.008/GB for private. Alternative: Docker Hub. Tag images with the Git SHA for deterministic rollbacks.

Secrets Management

Store all credentials in GitHub Actions Secrets (never in code or .env committed to the repo). Use environment-scoped secrets in GitHub to prevent staging secrets from reaching production jobs. Rotate the Neon database password and Fly API token quarterly.

Observability for a seasonal platform has two distinct modes: a low-overhead baseline during the off-season, and active monitoring during the Feb–May peak window.

Alerting Thresholds

Seasonal Runbook

• January 15: Enable uptime monitoring alerts. Review Fly.io autoscale limits. Verify connection pooler is healthy.
• February 1: Switch to active monitoring mode. Set Sentry alert frequency to immediate. Enable daily DB backup job.
• May 31: Disable expensive alerting. Reduce DB to minimum tier. Pause read replica.
• Off-season: Weekly uptime check is sufficient. Sentry digest mode.

All estimates assume a single-founder or small team operating at early-stage scale (thousands of users, not millions). Costs grow linearly with adoption; the architecture supports this without structural changes.

Cost Breakdown by Service

COPPA Compliance Infrastructure

Infrastructure Security Controls

COPPA Data Handling Schema

-- Separate schema for child PII
CREATE SCHEMA child_data;

-- Row-level security — only the owning parent can read
ALTER TABLE child_data.profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY parent_owns_child
  ON child_data.profiles
  USING (parent_user_id = current_setting('app.current_user_id')::uuid);

-- Audit log every access to child records
CREATE TABLE child_data.access_log (
  id          uuid DEFAULT gen_random_uuid() PRIMARY KEY,
  child_id    uuid NOT NULL,
  accessor_id uuid NOT NULL,
  action      text NOT NULL,
  accessed_at timestamptz DEFAULT now()
);

Privacy Policy Requirements

The COPPA privacy notice must be separate from the general privacy policy and written in plain language understandable to parents. It must describe: (1) what information is collected from children, (2) how it is used, (3) whether it is disclosed to third parties, and (4) the parent's rights to review, delete, and withdraw consent. Consult a privacy attorney before launch.

Disaster recovery for OneSummer is primarily a data recovery problem. The frontend and API are stateless and redeploy from Git in under 5 minutes. The database is the only component that requires a formal recovery procedure.

Failure Scenarios and Responses

Database Recovery Runbook

# Step 1: Identify the restore point
# For Neon PITR — use the Neon console or CLI
neon branches create \
  --name recovery-attempt \
  --parent main \
  --timestamp "2025-03-15T14:30:00Z"

# Step 2: Verify data integrity on the recovery branch
psql "$RECOVERY_DATABASE_URL" -c "SELECT count(*) FROM applications;"

# Step 3: Promote the recovery branch to production
# (swap the DATABASE_URL environment variable in Fly.io)
fly secrets set DATABASE_URL="$RECOVERY_DATABASE_URL" -a onesummer-api

# Step 4: Restart the API machines
fly machines restart -a onesummer-api

# Step 5: Verify application health
curl https://api.onesummer.com/health

Annual DR Test

Run a full database recovery drill each January (before peak season begins). Restore the production database to a staging environment using a 30-day-old backup and verify application functionality. Document the test results and update this runbook with any lessons learned.

Complete all items before accepting real user data. Items marked with a legal or compliance tag require external review.

• Infrastructure
• Production domain configured with DNS pointing to Netlify; HTTPS enforced via HSTS with max-age=31536000
• Fly.io production app deployed; min_machines = 0 confirmed; max_machines = 10 set for burst capacity
• Neon production database provisioned; connection pooler URL tested; migrations applied clean on main branch
• All secrets stored in GitHub Actions Secrets and Fly.io secrets; no credentials in code or committed .env files
• Cloudflare R2 bucket created with private ACL; presigned URL generation tested end-to-end
• Upstash Redis instance provisioned; rate limiting middleware tested and confirmed blocking at threshold
• CI / CD
• All three GitHub Actions workflows (ci.yml, preview.yml, deploy.yml) passing on a test PR and merge
• Post-deploy smoke tests hitting at least: health endpoint, auth flow, DB read, DB write
• Rollback procedure tested: deploy an intentionally broken image, confirm failure detection, execute rollback, confirm recovery
• Dependabot enabled on the repo with weekly schedule for both npm and Docker base image
• Security
• Content Security Policy header validated with CSP Evaluator; no unsafe-inline or unsafe-eval
• All API endpoints authenticated; no unauthenticated routes expose PII
• SQL injection test suite passing; no raw string interpolation in query builder
• Database row-level security policies verified on child_data schema
• Penetration test or security review completed (even informal — OWASP Top 10 checklist minimum)
• COPPA / Legal Requires Attorney Review
• Age gate implemented and tested: users under 13 are blocked from completing profile until parental consent is verified
• Parental consent email flow tested end-to-end: token generation, email delivery, consent recording, account activation
• COPPA-compliant privacy notice published — written for parent audience, reviewed by privacy counsel
• Data deletion mechanism implemented: parent can request deletion of all child data via a documented process; deletion confirmed within 10 business days
• No third-party analytics, tracking pixels, or session recording active on any page reachable by a child account
• Terms of Service and Privacy Policy finalized and linked from footer, registration flow, and cookie banner
• Monitoring
• Sentry initialized in both frontend and API; test error captured and visible in dashboard
• Uptime monitoring configured for api.onesummer.com/health and onesummer.com; SMS/Slack alert tested
• Logtail log drain connected to Fly.io; structured logs visible with request ID correlation
• Daily DB backup cron job enabled and first backup confirmed in R2 storage
• Disaster Recovery
• Neon PITR confirmed working: restored staging to a point 1 hour prior; application loaded correctly
• Runbook for all failure scenarios reviewed and accessible to all team members (not just the person who wrote it)
• Emergency contact list current: Neon support, Fly.io support, domain registrar, privacy counsel