Invio: a self-hosted invoicing tool that trades features for a shareable link
Self-hosted invoicing without the bloat.
At a glance
- What is it?
- Invio is a TypeScript invoicing application you host yourself, built around creating an invoice and sending a client a link instead of an account invite. The pitch is minimalism; the constraint is that almost everything you would want to verify lives in a wiki, not the README.
- Who is it for?
- Adopt Invio if you issue a modest number of invoices, you already run a host, and you specifically want clients to open a link rather than create an account. Do not adopt it if you need accounting integration, tax reporting, or a vendor with a support contract, and do not adopt it on the strength of the README alone.
- Can I use it commercially?
- Yes. Unlicense is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Invio picks, and the one it ignores
Most invoicing software assumes you want a system of record. It wants your chart of accounts, your tax rates, your recurring billing rules, your payment reconciliation. Invio assumes the opposite: you want to produce a document, hand it to a client, and get paid. The README frames this as "Zero Bloat" and describes the loop as "Create an invoice, share a link, get paid." That is the whole product thesis, and it determines who the tool is for. Freelancers, small studios, and anyone billing a handful of clients per month who already has somewhere else to keep books. It is not for a company that needs an audit trail tied to a general ledger, because nothing in the material suggests Invio produces one. The second claim in the README, that clients skip the "how do I log in?" email because they receive a secure link with no account required, is the actual differentiator. Account creation is the step where small invoices go unpaid, and removing it is a real design decision rather than a cosmetic one.
What the repository actually shows about the architecture
The repository is TypeScript, and the README points to a wiki for setup rather than documenting an install inline. That is the single most important fact for anyone evaluating Invio: the README is a landing page. It carries a banner, four screenshots (Dashboard, Invoice Creation, Settings, Invoices), a contributor grid, and a link to the Quick Start guide. There is no architecture section, no environment variable table, no database schema, and no description of how a shareable invoice link is generated or what protects it. The screenshots imply a dashboard-centric web application with a settings area, which is what you would expect from a self-hosted server-rendered or SPA front end, but the material does not confirm the stack, the persistence layer, or the authentication model. Treat the wiki as the source of truth and the README as a signpost.
Getting it running means leaving the README
The README's Quick Start section contains a single instruction: follow the Quick Start guide in the documentation. There is no docker run command, no docker compose snippet, no npm install line, and no .env example in the supplied material. The homepage at invio.dev and the live demo at demo.invio.dev are the two places the README directs you for a working instance, and the wiki at github.com/kittendevv/Invio/wiki is where the install steps live. If you are evaluating Invio for a team, that gap matters operationally: you cannot size the deployment, plan a backup strategy, or estimate the configuration surface from the repository page. The honest position is that the commands exist but are not in the material supplied here, so any article that prints a docker compose file for Invio is inventing it. Open the Quick Start page first and read it end to end before you clone anything.
The release history is thin and the tags are inconsistent
Three releases are listed: v2.2.0 in August 2026, v2.1.1 in June 2026, and one tagged V2.0.2 but labelled V2.1.0 in May 2026. That mismatch between tag and release title is worth noting because it is exactly the kind of detail that breaks automated upgrade tooling. If you pin images or packages by tag, verify which artefact the V2.0.2 tag actually points to rather than trusting the display name. The cadence, roughly a release every two to three months, suggests an actively maintained project with a small surface area, which is consistent with the minimalist claim. It also means there is no long-term support branch and no evidence in this material of a documented migration path between major versions. Back up your data before crossing a major version boundary, and read the release notes for v2.2.0 specifically, since the jump from 2.1.1 to 2.2.0 is where schema changes would land.
Link-based access is the feature and the failure mode
Removing client accounts solves a real friction problem, but it moves the security boundary onto the link itself. The README calls the link "secure" without defining what that means: whether it expires, whether it can be revoked, whether it is guessable, whether viewing it is logged. Those are the questions to ask before you send an invoice to a client, because a forwarded link is a link in someone else's inbox. This is not a reason to avoid Invio; it is a reason to read the wiki's section on invoice links and to decide whether your clients' tolerance for link-sharing matches your own. Compare it to a portal-based tool where the client authenticates: that model is slower to onboard and harder to lose control of. Invio has chosen the first trade-off deliberately, and the material does not show any compensating control.
What Invio is not, and what to use instead
If you need double-entry bookkeeping, VAT or sales tax returns, multi-currency ledgers, or bank reconciliation, Invio is the wrong layer. The appropriate alternative is accounting software such as a self-hosted ledger or a hosted accounting service, where the invoice is a byproduct of the books rather than a standalone document. The difference in approach is fundamental: Invio treats the invoice as an artefact you send, while accounting software treats it as a journal entry that happens to have a PDF. If instead your problem is collecting payment rather than issuing the document, a payment platform with hosted checkout pages covers the same client-facing link idea but owns the money movement and the compliance around it. Invio, based on the material, is the document layer. Pick it for that and nothing else.
Licence and the cost of running it yourself
Invio is released under the Unlicense, which is a public-domain dedication rather than a permissive licence with conditions. In practice that means you can modify, redistribute, and use it commercially without an attribution requirement, and there is no copyleft obligation on your own code. This is not legal advice; if your organisation has a licence review process, the Unlicense's public-domain framing is unusual enough that it is worth a five-minute check with whoever signs off on dependencies. The maintenance cost is the other side of self-hosting. You own the host, the backups, the TLS certificate, and the upgrade cycle, and the release cadence above means upgrades arrive a few times a year. The README's "Free. Forever." claim is accurate about the software and silent about the infrastructure, which is the honest way to read it: no subscription, but also no one to call when the container will not start.
Editorial conclusion
Adopt Invio if you issue a modest number of invoices, you already run a host, and you specifically want clients to open a link rather than create an account. Do not adopt it if you need accounting integration, tax reporting, or a vendor with a support contract, and do not adopt it on the strength of the README alone. Before you commit, read the Quick Start page in the wiki, confirm which database and storage backends the current release expects, and check the v2.1.0 to v2.2.0 release notes for migration steps, since the tag naming in the release list is inconsistent enough that you should not assume the upgrade path is automatic.
Community notes