# Cove Stack: a minimal TanStack Start template

> Cove Stack combines TanStack Start, Better Auth, Drizzle ORM, PostgreSQL, shadcn/ui, Vite Plus, and Nitro in a small TypeScript starter. It suits developers who want an opinionated SaaS foundation without adopting the workspace-oriented cove-monorepo template.

**mugnavo/cove** — The Cove Stack: 🏝️ minimal TanStack Start template with Vite+, Better Auth, Drizzle ORM, shadcn/ui

- Repository: https://github.com/mugnavo/cove
- Website: https://cove.mugnavo.com
- Stars: 1,398 · Forks: 88
- Language: TypeScript
- License: Unlicense
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mugnavo-cove

## What Cove Stack assembles for SaaS development

Cove Stack addresses the repetitive setup required to start a TypeScript SaaS application. The repository presents itself as a minimal starter for TanStack Start rather than a finished application or a reusable business framework. It is aimed at developers who want a working selection of authentication, database access, routing, UI, validation, and local tooling before writing product-specific features.

The application layer uses React with TanStack Start, TanStack Router, and TanStack Query. Drizzle ORM connects the application to PostgreSQL, while Better Auth supplies the authentication foundation. The interface starts with Tailwind CSS, shadcn/ui, and Base UI. Vite Plus provides the development environment and command layer, and Nitro is configured as the production server layer.

That combination has a clear bias. A developer receives several decisions already connected, including environment validation, auth middleware, a theme toggle, database scripts, and UI tooling. This reduces the number of initial choices, but it also means the generated project is not neutral. Adopting Cove Stack means accepting a PostgreSQL database, Better Auth, the selected component foundation, and Vite Plus, then replacing or removing what does not belong in the intended product.

The repository also offers a separate cove-monorepo template for pnpm workspaces. Cove Stack itself should not be confused with that workspace-oriented monorepo variant. Projects needing multiple deployable packages or workspace-level organization should inspect the companion repository before choosing this template.

## Cove Stack's TypeScript request and database flow

Based on the repository layout, a request moves through TanStack Start and Nitro while the source remains TypeScript. Vite Plus handles development and builds, while Nitro produces the server output referenced by the `start` script. The package configuration runs that output with `node .output/server/index.mjs`. This gives the project a defined server entry point, but the README does not document the route tree, server function inventory, or the complete request sequence.

Persistence follows the Drizzle and PostgreSQL path. The repository includes `drizzle.config.ts`, database commands, and a PostgreSQL service in `docker-compose.yml`. Better Auth is paired with `@better-auth/drizzle-adapter`, while the auth schema is stored at `src/lib/db/schema/auth.schema.ts`. If the Better Auth configuration changes, `auth:generate` regenerates that schema before a new migration is generated and applied. The middleware example at `src/lib/auth/middleware.ts` provides a place to enforce authentication on server functions and API routes, but it is explicitly a sample rather than a complete access-control policy.

Environment handling is unusually strict for a starter. Varlock owns the contract in `.env.schema`, validates `.env.local`, and generates types. Application code imports `ENV` from `varlock/env` instead of reading `process.env` directly. This avoids scattered ad hoc environment access, but it also makes `.env.schema` a required deployment interface. Any hosting platform must supply variables that conform to that schema.

For observability, evlog is wired through Nitro and emits one structured event per request. The README does not say that production delivery is configured by default. A drain must be added when logs need to reach a selected provider.

## Installing Cove Stack and starting PostgreSQL-backed development

The documented prerequisites are specific: Node.js 24 or newer, pnpm 12 or newer, and Vite Plus installed as `vp`. A new project can be created through the CLI shown by the README. This route is preferable when the developer wants Cove's generated project structure rather than manually copying the GitHub template.

```bash
pnpm create cove
```

The command opens the project creation flow. The README also links to GitHub's template workflow, which offers the same starter through the `cove` template.

Next, create `.env.local` with local values based on `.env.schema`. Secrets belong in that uncommitted file. After entering the values, load and validate them through Vite Plus:

```sh
vpr env:load
```

The repository includes a PostgreSQL container definition, but the README does not document a command for starting it. The `db` service exposes port `5432`, creates a `cove` database, and uses the local credentials declared in `docker-compose.yml`. Those file values should not be treated as production credentials.

With PostgreSQL available and the environment loaded, generate the initial Drizzle migration and apply it:

```sh
vpr db generate
vpr db migrate
```

The first command creates the migration from the configured schema. The second applies pending migrations to the connected database.

Start the application with:

```bash
vpr dev
```

The README says the development server will then be available at `http://localhost:3000`.

## Testing Cove Stack without retaining prototype scaffolding

Cove Stack includes a deliberately small testing foundation based on Vitest and Playwright. This is useful because authentication, server rendering, and database-backed applications can develop defects that component checks alone will not expose. At the same time, the documentation explicitly allows developers to remove this foundation for short-lived prototypes.

Run unit and local integration tests once with:

```bash
vpr test
```

The README states that this is equivalent to Vite Plus's built-in test command. For an interactive development cycle, use:

```bash
vpr test watch
```

End-to-end coverage has a separate cost because it builds the application before invoking Playwright:

```bash
vpr test:e2e
```

The package script includes `--pass-with-no-tests`, so the command can succeed when no Playwright tests exist. That behavior is convenient immediately after generation, but it does not establish browser coverage. A team adopting the template must add tests relevant to its routes, authentication flows, and database behavior.

Other quality commands map to Vite Plus. `vpr check` runs the repository's combined checks, while separate formatting and lint scripts are also available. The template should not be treated as having an established application test strategy by default. Its examples and commands provide a starting structure, not evidence of coverage for future product behavior.

## Cove Stack dependencies, upgrades, and production boundaries

Dependency maintenance is selective because Cove Stack pins package versions. The README notes that a newly created project can contain versions that are slightly behind by the time the CLI is used. It offers `vpr deps` for selective upgrades, while `package.json` shows that this invokes taze with a maturity period of three months. This can reduce surprise upgrades, but the developer remains responsible for reviewing transitive changes and application compatibility.

The repository also lists components that carry release risk. TanStack Devtools is described as alpha and subject to breaking changes. Nitro is configured with the v3 beta by default. Drizzle ORM v1 is identified as a release candidate with relations v2. These are direct project dependencies or configured technologies, not hypothetical future upgrades. A team that requires conservative release channels must resolve these boundaries before shipping.

Nitro supports deployment presets including Netlify, Vercel, Node.js, and others, but support for a preset does not configure every surrounding service. Authentication still requires correct secrets and database connectivity. Structured request events still need a production drain. The environment contract still needs to be mapped to the host. PostgreSQL hosting and backup policy are outside the template.

The local PostgreSQL definition uses `postgres:alpine`, port `5432`, a persistent `postgres_data_cove` volume, and credentials written directly in `docker-compose.yml`. It is suitable repository scaffolding, but the README does not describe hardening, remote access, backups, or production credential rotation. Those concerns need an environment-specific answer.

Cove Stack is released under the Unlicense, which the README describes as placing the template code in the public domain. It also says developers can remove or replace the code in their own project. This is a permissive starting point, but it does not resolve licensing for separately installed dependencies, hosted services, or copied third-party assets. Those require separate review rather than a conclusion based on the template license alone.

## When Cove Stack is preferable to a monorepo template

Cove Stack is the more direct choice for a single TanStack Start application. It already includes the README's main application concerns: routing, server rendering, PostgreSQL access, authentication, environment validation, UI components, migration commands, and request logging. A developer can remove the sample theme controls or middleware and build within a conventional application tree.

The cove-monorepo template takes a different structural approach by using Vite Plus and pnpm workspaces. It is more relevant when a project needs explicit workspace boundaries or several related packages. The README does not provide enough detail to claim specific package layouts or deployment behavior, so the practical distinction is the monorepo boundary itself. Cove Stack should not be selected merely because it uses pnpm, since the companion template exists specifically for the workspace-oriented case.

Another alternative is assembling TanStack Start directly with separate generators and documentation. That route offers more control over every dependency, but the developer must connect and verify the pieces manually. Cove Stack accepts a PostgreSQL and Better Auth baseline in exchange for less initial assembly. It is also the wrong choice when those choices are unwanted or when a minimal site does not need an ORM, auth adapter, migration flow, or SaaS-oriented component foundation.

Cove also has relevant upgrade and adoption costs. Its dependencies are pinned, some technologies are prerelease, and production logging is not complete until a drain is added. Those costs are visible and bounded, but they should be accepted as part of the template rather than discovered after a product has been built on it.

## Conclusion

Cove Stack fits developers who already want React, TanStack Start, Better Auth, PostgreSQL, and Vite Plus and are willing to replace starter code with their own product architecture. It is a poor fit for a server-rendered site with no PostgreSQL requirement or for teams that need production log delivery without adding a drain. Before adoption, verify the environment schema against the target deployment, review the alpha and release-candidate dependencies, and confirm that Nitro's selected deployment preset matches the hosting platform.

## FAQ

### What prerequisites does Cove Stack require?

The README requires Node.js 24 or newer, pnpm 12 or newer, and Vite Plus installed as `vp`.

### How do I create the initial Cove Stack database migration?

After loading the environment and making PostgreSQL available, run `vpr db generate` and then `vpr db migrate` to create and apply the initial migration.

### Does Cove Stack send production logs to a provider by default?

No provider delivery is documented by default. evlog emits one structured event per request, and the README says a drain should be added when production needs logs sent to the chosen provider.

## Sources

- [Issues](https://github.com/mugnavo/cove/issues)
- [License: Unlicense](https://github.com/mugnavo/cove/blob/main/LICENSE)
- [mugnavo/cove on GitHub](https://github.com/mugnavo/cove)
- [Project website](https://cove.mugnavo.com)
- [README](https://github.com/mugnavo/cove/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mugnavo-cove