Vuesion builds on the configuration mechanisms provided by Nuxt, Prisma, and the surrounding tooling.
Rather than introducing another custom configuration layer, Vuesion follows the conventions of the technologies it is built on.
This makes the project immediately familiar to developers already working with the Nuxt ecosystem while keeping configuration predictable.
Configuration is typically divided into three categories:
Environment
│
▼
Framework
│
▼
Project
Each layer has a different responsibility.
Environment variables configure values that differ between environments or contain sensitive information.
Typical examples include:
Vuesion intentionally keeps these values outside the source code.
For example:
DATABASE_URL=...
NUXT_SESSION_PASSWORD=...
RESEND_API_KEY=...
Some environment variables are required for every installation.
Examples include:
DATABASE_URLNUXT_SESSION_PASSWORDOthers only become necessary when a particular feature is enabled.
For example:
NUXT_OAUTH_GITHUB_CLIENT_IDNUXT_OAUTH_GITHUB_CLIENT_SECRETRESEND_API_KEYNUXT_SUPABASE_URLNUXT_SUPABASE_SERVICE_ROLE_KEYNUXT_SUPABASE_STORAGE_BUCKETNUXT_PUBLIC_CDN_URLThis keeps local development lightweight while allowing production installations to enable additional services as needed.
Several environment variables customize the product branding without modifying the application itself.
Examples include:
This allows the same application to be reused across different products while maintaining consistent branding.
The central application configuration lives inside:
nuxt.config.ts
This file configures:
Whenever possible, Vuesion follows the standard Nuxt configuration patterns instead of introducing project-specific alternatives.
Values required by the browser are exposed through Nuxt's runtime configuration.
Server-only values remain private.
This separation prevents secrets from accidentally becoming available on the client while still allowing browser code to access public configuration when necessary.
Most development tools manage their own configuration.
Examples include:
eslint.config.ts
stylelint.config.mjs
vitest.config.mts
playwright.config.ts
prisma.config.ts
content.config.ts
Each tool follows its own standard configuration format.
Keeping configuration close to the corresponding tool makes updates easier and avoids introducing another abstraction layer.
Vuesion intentionally follows the conventions of the underlying ecosystem.
Instead of introducing custom configuration formats, the project uses the configuration mechanisms already established by:
Developers familiar with these tools should therefore immediately recognize where configuration belongs.
A typical local setup requires only a small number of environment variables:
Additional integrations such as email delivery, OAuth providers, or cloud storage can be configured when they become relevant for the project.
This keeps the first local setup straightforward while allowing production environments to enable additional capabilities.
Vuesion does not prescribe a particular deployment platform.
Because it is built on Nuxt, it can be deployed anywhere supported by Nuxt.
Deployment strategies differ significantly between projects and are therefore intentionally left outside the scope of this documentation.
Refer to the official Nuxt deployment documentation for platform-specific guidance.
Configuration should feel familiar.
Rather than introducing another layer of project-specific configuration, Vuesion builds upon the conventions already established by the tools it uses.
This provides:
The result is a project that feels like a well-organized Nuxt application rather than a framework built on top of Nuxt.
Continue with Database to learn how Vuesion organizes its Prisma schema, migrations, and data model.