Kurrier: a self-hosted web workspace that sits on top of your existing mail and storage
Kurrier is a modern, self-hosted workspace for email, calendar, contacts and storage.
At a glance
- What is it?
- Kurrier is a TypeScript workspace that puts email, calendars, contacts and file storage behind one web interface, connecting to IMAP, SMTP, CalDAV, CardDAV, WebDAV, S3 and OIDC rather than replacing them. This looks at the architecture, the deployment story, and what a self-hosted label does and does not mean here.
- Who is it for?
- Kurrier fits a team or individual who already runs or buys IMAP mail, CalDAV and CardDAV servers and object storage, and who wants one modern interface across them without moving the data. It does not fit someone who wants a complete mail platform, because Kurrier is a client and console for infrastructure you provide, and it is the wrong choice if you need a provider-agnostic mail server.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 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 October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A console for infrastructure you already have
Kurrier is described as a modern, self-hosted workspace for email, calendars, contacts and storage, and the phrase that explains the design is in the subtitle: open-source communication infrastructure, under your control.
The important word in the feature list is connect. The documentation says Kurrier connects the providers and infrastructure you already use while giving you a unified web interface built around open standards, and that it is designed to work with existing infrastructure rather than replace it. Bring your mail provider, your object storage and your identity provider, and run the application on infrastructure you control.
That framing is the whole product decision. A workspace can be built two ways: as a suite of servers that host your mail, your files and your identity, or as a client and console that speaks to servers you already have. Kurrier is the second, and the audience is a team that has already chosen its providers and wants one interface over them.
The features are grouped accordingly. Email covers IMAP, SMTP, Amazon SES, SendGrid, Mailgun and Postmark. Calendars cover CalDAV with synchronization across compatible devices and applications. Contacts cover CardDAV address books and synchronization. Storage is integrated WebDAV and S3-backed file storage. Authentication covers local accounts, Google, and standards-based OIDC and SSO. And there is a management API for programmatic provisioning and integration with external systems.
The project is written in TypeScript, and the site is kurrier.org with the documentation at kurrier.org/docs.
The protocol list is the design
Kurrier uses established protocols wherever possible, and the documentation names them: IMAP, SMTP, CalDAV, CardDAV, WebDAV, OIDC and JMAP.
That list is the architecture, and it is worth reading closely, because the choices inside it are not all the same kind of decision. IMAP and SMTP are the mail protocols, and they are what make a self-hosted mail provider possible, which is why SES, SendGrid, Mailgun and Postmark appear alongside SMTP as mail options. CalDAV and CardDAV are the calendar and contacts equivalents, and their presence in the list is the same argument in a different protocol. WebDAV and S3 are two ways to reach the same storage layer, one a file protocol and one an object API.
OIDC sits with them rather than apart, because the point of a standards-based identity provider is that the workspace does not become the place your identity lives. And JMAP appears in the list as well, which is the newer mail standard, alongside the older ones.
The stated benefit is interoperability: it keeps Kurrier interoperable with existing servers, providers, desktop clients and mobile applications without locking your data into a proprietary ecosystem. That is the argument for a self-hosted workspace in one sentence, and it is also the argument against choosing one that stores your mail in a format only it can read.
The project also hosts commercial offerings, Kurrier.io for email infrastructure and team workflows and Kurrier Mail for a hosted email workspace, so the open source project and the hosted products sit side by side.
A pnpm workspace with a web app, a worker and a docs site
The repository is a pnpm workspace with three applications and a shared package directory, and the manifest shows the whole development shape.
There is `apps/web`, `apps/worker` and `apps/docs`, driven by separate scripts that each use `pnpm --prefix` to run in the right place, with `dotenvx run -f db/local/.env` supplying the environment. A single `dev` script runs all three concurrently. The web build runs `pnpm --prefix apps/web build` inside the web app, and the repository topics name Next.js, Nitro.js and Tailwind CSS.
The database layer is separate again, in a `db/` directory, with `drizzle-kit` for the schema and a migration script that runs `tsx db/db-migrate.ts`. The `app:migrate` script points at `db/local/.env`, so a local database is a first class part of the setup rather than an afterthought.
The tooling is current rather than legacy. The package manager is pinned to `[email protected]`, the engine requirement is Node `24.20.0`, linting and formatting are Biome with `biome check` and `biome format --write`, and releases go through changesets with `changeset version` and `changeset publish`. There is a `check:locales` script, which means translations are validated in CI rather than drifting.
The root package version is 0.0.3 and the package is private, while the published release tags are v4.3.0, v4.2.0 and v4.1.1 from September 2026. The version numbers live in the individual workspace packages rather than in the root, which is why the two do not line up.
Deployment: Docker, an Unraid template, and git subtree pushes
The self-hosted story is handled in a few different ways in the repository, and the details tell you what kind of deployment it expects.
The documentation says Kurrier includes Docker-based deployment support, and the configuration, installation requirements, provider setup, authentication, APIs and deployment instructions are all maintained in the documentation rather than in the readme. That is a deliberate split: the readme stays short, the docs carry the operational detail.
The repository itself shows three deployment shapes. There is `kurrier-unraid.xml`, an Unraid template, which tells you a large part of the audience runs these services on a home server with a NAS operating system. There are the subtree push scripts, `deploy:db` which does a `git subtree split --prefix=db` onto a `deploy` branch and pushes it, and `deploy:docs` which pushes the `apps/docs` subtree to a `dokku-docs` branch. That is a Dokku deployment pattern, where the app is deployed by pushing a branch.
And there is the ordinary path, the `build` script running `pnpm --prefix apps/web build` with the environment from `db/.env`, plus the `apps/worker` build for the background worker.
The split between the web app and the worker is worth noting for an operator. The worker is the piece that has to be running for the workspace to do its scheduled and synchronisation work, and it is deployed and scaled separately from the front end.
What self-hosted means here, and what it does not
The honest limit of this project is worth stating directly, because the phrase self-hosted workspace can be read more broadly than it should be.
Kurrier does not provide a mail server, a calendar server, an address book server or an object store. Those are the things you bring. The application connects to them over IMAP, SMTP, CalDAV, CardDAV, WebDAV and S3, and it gives you a web interface, a management API and a place to configure how those connections behave.
That has two consequences. The first is favourable: your data stays in servers you already understand, and if you leave the project, you still have working clients for your mail and your files. The second is a requirement: running Kurrier well means you still have to run, secure, back up and update those servers. A team that assumed the workspace would replace its mail infrastructure would be disappointed.
It also means the feature set is bounded by what the protocols expose. A CalDAV server that does not support a particular scheduling extension will not become schedulable because Kurrier wants it to be, and the synchronisation behaviour is only as good as the server on the other end.
The other side of the same coin is the interoperability claim, and it is a real one. Because everything goes over open protocols, a client that is not Kurrier can still read the same data, and Kurrier can talk to providers it has never heard of as long as they speak the protocol. For an organisation that has been through one round of a proprietary mail platform, that is usually the deciding factor.
Licence, trademark, roadmap and the commercial side
On licensing, the metadata lists the licence as a custom one that GitHub cannot classify, with a pointer to the `LICENSE` file at the repository root. There is a `NOTICE` file beside it. A custom licence for an open source project is not automatically a problem, but it is not a standard grant either, so the file itself is the thing to read, particularly if you intend to modify the application or offer it to users.
The `TRADEMARK.md` file at the root is a separate matter from copyright, and it is the file to look at before you rebrand. The project also ships `VISION.md` and `ROADMAP.md`, which tell you where the maintainer intends the project to go, and `SECURITY.md` for reporting vulnerabilities.
The business model is visible in the readme. There are hosted offerings, Kurrier.io for email infrastructure and team workflows and Kurrier Mail for a hosted email workspace, and a Stripe payment link for supporting development. The readme also asks directly for GitHub stars and for sharing the project, which is a candid description of how a self-hosted project grows its contributor base when the code is not the product.
On maintenance, the release line is active. v4.1.1 was published on 2026-09-19, v4.2.0 on 2026-09-20, and v4.3.0 on 2026-09-24, with the last push to the repository on 2026-09-28. Three releases in six days is a fast cadence for a platform of this scope, and it is a good sign that the pieces are still being finished rather than merely maintained.
Editorial conclusion
Kurrier fits a team or individual who already runs or buys IMAP mail, CalDAV and CardDAV servers and object storage, and who wants one modern interface across them without moving the data. It does not fit someone who wants a complete mail platform, because Kurrier is a client and console for infrastructure you provide, and it is the wrong choice if you need a provider-agnostic mail server. Before you adopt it, confirm which of your existing servers already speak CalDAV and CardDAV, read the licence file, which is a custom one rather than a standard open source grant, and check the TRADEMARK.md file if you intend to rebrand it.
Frequently asked questions
What does Kurrier actually run?
It is a self-hosted workspace for email, calendars, contacts and storage that connects to providers you already use: IMAP, SMTP, Amazon SES, SendGrid, Mailgun and Postmark for mail, CalDAV for calendars, CardDAV for contacts, and WebDAV or S3 for storage. It is designed to work with existing infrastructure rather than replace it.
Which standards does Kurrier use?
The documented protocol list is IMAP, SMTP, CalDAV, CardDAV, WebDAV, OIDC and JMAP. The stated purpose is to keep Kurrier interoperable with existing servers, providers, desktop clients and mobile applications rather than locking data into a proprietary ecosystem.
How do I deploy Kurrier?
The project includes Docker-based deployment support, and the documentation at kurrier.org/docs carries the configuration, installation requirements, provider setup, authentication and deployment instructions. The repository also ships an Unraid template, kurrier-unraid.xml, and git subtree push scripts for a Dokku style deployment.
How is Kurrier built?
It is a pnpm workspace with `apps/web`, `apps/worker` and `apps/docs`, a shared `packages/` directory and a `db/` directory with Drizzle migrations run through `tsx db/db-migrate.ts`. The package manager is pinned to pnpm 10 and the engine requirement is Node 24.20.0, with Biome for linting and changesets for releases.
What licence is Kurrier released under?
The licence is listed as a custom one that GitHub cannot classify, with the terms in the LICENSE file at the repository root and a NOTICE file beside it. The repository also carries a TRADEMARK.md file, which is the one to read before rebranding or offering the project under your own name.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kurrier-org-kurrier)Was this useful?