Oolvay is a production SaaS starter kit, not a black-box platform. You own the codebase, the infrastructure accounts, the database, the billing providers, and the operational settings.
This page explains the ideas that show up across the rest of the documentation.
Most product behavior starts in config/site.ts.
Branding, metadata, auth defaults, email settings, payment providers, tiers, security limits, analytics, notifications, and operational defaults are controlled through typed configuration before you touch feature code.
Configuration is the first layer. Source code is still available when you need deeper changes.
Oolvay does not hide third-party services behind a managed backend. You connect your own providers and keep control of the accounts.
Examples include:
This means production readiness depends on your provider accounts being configured correctly. The starter kit gives you the integration points and defaults, not a shared hosted control plane.
Client UI is never the source of truth for privileged behavior.
Buttons, sidebar items, and settings forms can hide actions from users, but authorization is enforced in server components, route handlers, and server actions.
Common examples:
guardAction() before doing protected workEach subsystem has a narrow job, but they are designed to work together.
0 / 2,000 characters
Authentication creates the user session. RBAC decides access. Email sends login and system messages. Payments update tiers. Notifications inform users. Observability records what happened. Admin screens expose operational controls.
No single feature owns the whole app.
Most optional integrations can be disabled or left unconfigured.
If Redis is missing, sessions still work through the database. If analytics is disabled, the app runs normally. If Ably is disabled, notifications fall back to polling. If Inngest is disabled, supported work can run synchronously.
The goal is for the app to degrade predictably during setup.
A few files are intentionally central:
config/site.ts controls product and integration settingsenv.ts validates required environment variableslib/auth/auth.ts wires Better Auth and auth pluginsdb/schemas/* defines database tablesdb/types/* defines shared domain constantslib/guard-action.ts protects authenticated server actionslib/csp.ts builds the Content Security PolicyWhen you are unsure where behavior comes from, start with these files.
Start with config/site.ts.
Change brand details, enabled providers, pricing tiers, auth defaults, email senders, metadata, and operational limits there first.
Add environment variables.
Use .env.local for local development and your hosting provider’s environment variable settings in production.
Run the app and verify the affected flow.
Test the user-facing path and the admin-facing state change, especially for auth, payments, email, and storage.
Change source code only when configuration is not enough.
Most teams can get far by configuring the provided systems before adding new abstractions.
Getting Started covers the minimum path. Other sections are deeper references for systems you can configure when needed.
Optional systems are documented because they are available, not because every app needs all of them on day one.
If a control appears in the UI, assume there is a matching server-side rule behind it. Keep that pattern when adding your own features.