Ship Faster with a Real Runtime Boundary

The starter keeps request-bound infrastructure in packages/core so the app can stay content-first without collapsing runtime details into page code.

The boundary that matters

Public pages should not know how D1 clients are created, how auth is assembled, or how request context is injected. Those concerns belong in the runtime layer.

What the runtime owns

That gives you a stable place for:

• D1 access through Drizzle
• Better Auth server creation
• request-scoped runtime assembly
• R2 storage helpers

What the site keeps

The site stays focused on composition:

• content collections,
• layouts,
• page-level view models,
• feature-specific UI.

Why this speeds delivery

When runtime assembly is centralized, new pages do not need to repeat setup work or pull infrastructure concerns into the UI. The result is faster iteration with fewer accidental cross-layer dependencies.