Multi-Region Backend Configuration System

Problem/Feature Description

A cloud infrastructure company is expanding their Fastify API service from a single US region to three regions: US-East, EU-West, and APAC. The platform team has been burned multiple times by configuration drift between environments — developers accidentally deployed staging database credentials to production, and an engineer hard-coded if (env === 'production') branches that behaved differently than expected during the EU rollout.

The platform lead wants a strict, validated configuration system for the Fastify backend. It must fail fast at startup if any required settings are missing, and must be easy to use from any plugin without duplicating config loading logic. The company uses .env files locally but injects environment variables directly in CI/CD and Kubernetes.

The API itself is a simple service that exposes a health endpoint and an items endpoint, but the core requirement is the configuration layer. The app must be usable immediately without extra setup beyond environment variables.

Output Specification

Create a working Fastify application with the following structure and files:

• src/config.ts — configuration plugin
• src/app.ts — application builder that registers plugins and routes
• src/server.ts — entry point that starts the server
• package.json — with appropriate scripts and dependencies
• README.md — brief explanation of required environment variables and how to run

The app must expose:

• GET /health — returns { status: "ok" }
• GET /items — returns { items: [] }

The configuration must handle at minimum:

• PORT — server port, defaults to 3000
• HOST — bind address, defaults to 0.0.0.0
• DATABASE_URL — required database connection string
• JWT_SECRET — required secret, minimum 32 characters
• LOG_LEVEL — optional, defaults to info

The app should start successfully when the required variables are set, and fail with a clear error at startup if they are missing.