Invoicely: an open source invoicing app built on Next.js and tRPC

A full stack invoice app, not a template or a PDF service

Invoicely is described as a modern open-source invoice generation platform built with Next.js, tRPC and TypeScript. The stack listing is unusually complete for a project of this kind: Next.js 15.3.1 with the App Router, React 19, TypeScript 5.8.2, tRPC 11.1.2 for end to end typed APIs, TanStack Query 5.76.1 for server state and Jotai 2.12.3 for atomic client state, with Zod 3.25.7 for validation.

The data layer is Drizzle ORM 0.43.1 against a serverless Postgres, described as Neon Database, and authentication is Better Auth 1.2.8 with Google OAuth as the social provider. Files go to Cloudflare R2 object storage, and PDFs are produced with React PDF 9.2.1. The build system is Turbo 2.5.3 across workspaces, with ESLint 9, Prettier 3.5.3 and Husky 9.1.7 for the usual guards.

So this is an application you host, with a database, an auth layer, storage and a rendering pipeline. The project describes itself as simple and easy to use, and the home page for it is invoicely.gg. The licence is MIT, and the repository carries a Vercel OSS program badge.

Five commands and a Postgres database to get a running app

The prerequisites are stated precisely: Node.js 22.9.0 or higher, Yarn 4.9.1 or higher which is managed through the packageManager field, and PostgreSQL for the application data. The root package.json also pins the node engine to 22.9.0 or newer.

The clone and install are unremarkable.

git clone https://github.com/legions-developer/invoicely.git
cd invoicely

yarn install

Then the environment file is created from the example, and the symlinks that share environment variables across the workspace apps are generated by a script the repository calls env-links.sh and the root package.json exposes as sys-link.

# Create environment file in root directory
cp .env.example .env

# Create symlinks for environment variables across apps
yarn sys-link

The database is prepared in two steps, a schema generation and a migration, both routed through dotenv so the environment is loaded.

# Generate database schema
yarn db:generate

# Run database migrations
yarn db:migrate

The dev server starts with yarn dev, which runs the Turbo dev task across the workspaces.

yarn dev

What you should see is the Next.js application on port 3000, which is the port the environment example sets for the base URL, the auth URL and the tRPC base URL.

A monorepo where the database lives in its own workspace

The project structure section shows a Turbo monorepo with two workspace globs, apps and packages, and the layout explains how much is shared.

The web application sits in apps/web, and inside it the App Router pages, reusable components, constants, custom hooks, utility libraries, context providers, the tRPC configuration, TypeScript types and the Zod validation schemas each have their own directory. The public folder holds static assets and package.json holds the app dependencies.

The shared pieces are in packages. The db package carries the Drizzle schemas under src/schema, its exports in index.ts and the migration files in a migrations directory. The utilities package holds the environment configuration under src/env, and there are shared eslint-config and typescript-config packages so that lint and compiler settings are not copied between apps.

Two root level files are worth knowing about. env-links.sh is the environment symlink script that the sys-link script runs, and turbo.json holds the Turbo configuration that makes yarn dev, yarn build and yarn lint fan out across workspaces.

The structure is the reason the environment step exists. Because the database package and the web app both need the same variables, the project symlinks rather than duplicating, which is convenient until you deploy to a platform that mounts the workspace differently.

Two dependency patches that have to be removed when upstream catches up

This is the part of the project that most deserves an adopter's attention, because it describes live security workarounds rather than a clean dependency tree.

The first is a Yarn patch at .yarn/patches/braces-npm-3.0.3-security.patch that mitigates GHSA-vfj7-8cjw-p6xm by rejecting brace and parenthesis and AST nesting beyond 100 levels. The documentation states that no upstream patched release is available as of October 5, 2026, so version based scanners will still flag [email protected], and that the audit result for the patched tree only counts when it is paired with the patch regression tests. The instruction is to keep the upstream warning visible and replace the patch with a fixed release when one appears.

The second is a Sentry problem. @sentry/[email protected] is pinned to a patch at .yarn/patches/sentry-nextjs-npm-10.76.0-runtime.patch, because its server entry imports a build helper that eagerly calls createRequire with a filename, and OpenNext's Worker bundle supplies an empty filename, which breaks instrumentation startup and auth requests. The patch defers that call, and the note says to remove the patch, the resolution and the sentryRuntimePatch cache dependency in apps/web/next.config.ts once an upstream fix passes yarn test:security and auth requests against the built Worker.

The verification command is a single entry, and it runs three test files.

yarn test:security

A third item is a resolution rather than a patch: the node-gyp resolution removes the vulnerable make-fetch-happen to http-cache-semantics dependency chain, which is why the Node.js 22.9.0 floor is retained for that build tool. A separate command checks published advisories across all workspaces.

yarn npm audit --all --recursive --no-deprecations

The dashboard defines collected, outstanding and overdue in specific terms

The financial dashboard is described in enough detail to be useful, and the definitions matter more than the charts.

Collected covers invoices marked success, and monthly collections use the recorded payment date, while paid invoices without a recorded payment date remain in the all-time totals. Outstanding covers pending, error and expired invoices. Overdue is the subset that is past its due date or marked expired, and an invoice due today is not overdue.

Refunded invoices are excluded from amounts, monthly billed amounts use the invoice date, and clients are grouped by normalized name and address. Amounts use decimal arithmetic with each invoice rounded to two decimals to match invoice display precision, and currencies are never combined or converted.

Two limitations are stated and they are the ones to plan around. Partial payments are not supported, and there is no payment ledger. For a business that invoices on milestones or accepts part payment, that is not a small gap. The dashboard also reads existing invoice fields and needs no new database migration, environment variable or dependency, so it can be enabled without a schema change.

Cloudflare Workers hosting needs a staging pass before the domain moves

Deployment to Cloudflare Workers with OpenNext has its own guide at docs/cloudflare.md, and the README points at it for the full procedure, including staging validation and domain cutover. The root scripts expose the pipeline as build:cloudflare, preview:cloudflare, deploy:cloudflare and deploy:cloudflare:preview, with the preview deployment switching on the CLOUDFLARE_PREVIEW environment variable.

The staging step is not ceremony. The Sentry patch described earlier exists because the OpenNext Worker bundle breaks the Sentry server entry, and the note says the fix must be verified with auth requests against the built Worker, including the /api/auth/ok route and an unauthenticated /api/auth/get-session request. That is a built artifact check, and it is exactly the kind of thing a staging deployment catches and a local dev server does not.

The storage layer follows the same pattern. The environment example lists the R2 variables, the bucket name, the public domain, the endpoint and the access credentials, alongside the database URL, the Google OAuth client id and secret, the Better Auth URL and secret, the PostHog key and host, the Sentry auth token and DSN, and the tRPC base URL pointing at the /api/trpc path.

MIT licensed, no releases yet, and a contribution rule that is stated bluntlyly

The repository state is easy to summarise. The last push was on 2026-10-05, the repository is not archived, the licence field says MIT with the LICENSE file at the root, and there are no GitHub releases, so there is no version to pin. The root package.json still says version 0.0.1 and is marked private, which tells you the project is run from a clone or from a build rather than consumed as a published package.

The contribution policy is unusual enough to quote. The README carries a caution that the project does not allow vibe coding, and that a pull request will be rejected if the code quality is poor and vibe coded. For an open source project that is a filter rather than a deterrent, and it tells you something about how the maintainers intend to review incoming code.

The supporting evidence for that review process is the tooling around it. There are agent and assistant directories in the repository, .agents, .claude and .cursor, plus a CLAUDE.md file and a skills-lock.json, and the deployment scripts are accompanied by an llm directory. Hooks run through Husky, formatting is enforced with Prettier and a sort-imports plugin, and the shared packages keep lint and TypeScript configuration consistent.

For an adopter, the practical summary is that this is a young project with active development, an explicit security posture around its dependency tree, and a review culture that will not move quickly on large contributions.

Editorial conclusion

Adopt Invoicely when you want to generate and track invoices on infrastructure you control, when you can supply a Postgres database and object storage, and when your accounting model fits a single currency per invoice. Do not adopt it if you need to record partial payments, because the project states that partial payments and a payment ledger are not supported, and do not adopt it if multi-currency reporting matters, because currencies are never combined or converted. Before the first run, read the dependency security section, since the tree carries a patched braces release with no upstream fix, and if you deploy to Cloudflare Workers read docs/cloudflare.md first, because the OpenNext build requires a staging validation and a domain cutover rather than a direct push.

Frequently asked questions

Official sources

1. Issues
2. legions-developer/invoicely on GitHub
3. License: MIT
4. Project website
5. README