Your team’s whole day,
in one application.
Issues and projects, chat, documents and mail — not integrated, not synchronised. The same application, with people and assets already in it, and drive, calendar and CRM coming the same way.
curl -fsSL https://get.kernaio.com | bashNo card for the free plan · no limit on people when you self-host
Four tools that do not talk to each other.
An issue tracker. A chat app. A wiki. Something for HR. Four logins, four permission models, four searches — and every link between them is a copy-paste somebody has to remember to make.
The decision was made in a thread nobody can find.
The spec lives in a wiki that does not know the issue exists.
The new starter is in the HR tool but not in the project.
Someone is paid to keep four tools agreeing with each other.
Nothing is synchronised, because nothing is separate.
Kern is one application with modules inside it. They share a directory, a permission model, a search index and an activity log — so the joins between them are not integrations, they are just how the data sits.
An issue can have its own channel
Open a conversation on any issue. It is a real channel — searchable, with threads and files — that happens to belong to that issue.
A message becomes an issue
On the roadmapTurn a message into an issue and the thread comes with it. Nobody re-types the context, and nobody loses the conversation that started it. This is the other half of the seam, and it is on the roadmap rather than in the product.
The people are the same people
One directory and one set of permissions under every module, so a person joins once and appears everywhere they should. Today that is issues, chat, documents, mail, people and assets; every module we add inherits it rather than building its own.
Everything a company does in a day — eventually.
Turn on the ones you need; a workspace that only wants issues and chat sees only issues and chat. Kern is pre-1.0, so every card below says whether you can use it today or whether it is on the roadmap. Nothing here is behind a paywall either way.
Issues & projects
Everything the team owes each other, in one queue.
- List and board views
- Custom types and fields
- Workflows with approvals
Chat
Conversation that stays attached to the work.
- Channels, DMs and threads
- A channel on any issue
- Presence, typing, read state
Docs
Pages several people edit at once, with history, drafts and a published site.
- Real-time editing
- Version history and draft/publish
- Databases, diagrams and embeds
The mail your workspace sends, and what happened to every message.
- Sending per workspace
- Templates and a send queue
- Delivery log and bounces
Drive
Files, where the work already is.
- Folders and versions
- Share links with expiry
- Planned for v1.1
Calendar
One week, with everything on it.
- Personal and team calendars
- Cycles and leave overlaid
- Planned for v1.1
HR
The people in your projects are the people in your records.
- Directory, org chart and offices
- Leave and attendance with approvals
- Subject access and erasure
Inventory
What the company owns, who is holding it, and where it went.
- Asset register with custody
- Repairs, files and warranty
- Every change as history
Recruiting
From an open role to a signed offer.
- Pipeline as a board
- Interviews and scorecards
- Planned for v1.1
CRM
Deals, next to the work that delivers them.
- Contacts and companies
- Pipelines as boards
- Planned for v1.1
Automation
If this happens, do that — across every module.
- Trigger, condition, action
- Smart values
- Planned for v1.1
Calls
Talk without opening another tab.
- Audio and video
- Huddles in a channel
- Planned for v1.1
AI assistant
Your key, your model, your data.
- Bring your own provider
- Summaries and drafting
- Planned for v1.1
A module is a first-class citizen, including yours.
Every feature Kern ships is a module: it owns a Postgres schema, mounts its own API, contributes its own screens, declares its own permissions. The ones we wrote use the same public interfaces you would.
- Switch a module off and every trace of it goes — nav, routes, jobs, notifications
- A module cannot read another module’s tables; it asks through a contract
- Row-level security on the tenant tables, as a second lock
- Write your own against the documented interfaces
Same product. You choose who keeps it running.
There is no feature behind the paywall. The cloud sells you operations, not software.
Self-hosted
Free, forever
One command puts the whole platform on your server behind automatic HTTPS. Your database, your files, your backups, your rules.
- Every module Kern ships, and every feature in them
- Unlimited people and workspaces
- Upgrade and back up with one command each
- Nothing phones home
Kern Cloud
From $8 per user
The same code, run by us in Germany. Upgrades, certificates and backups are somebody else’s evening.
- A workspace in about a minute
- Upgrades the day they ship
- Nightly backups, kept 30 days, off the machine that serves you
- The same build as GitHub, so your own server can run it whenever you like
- Email support from the people who wrote it
The parts you only notice when they are missing.
Many workspaces, one inbox
Belong to a company, a client and a side project at once. Notifications from all of them arrive in a single inbox with a badge per workspace, over one connection.
Permissions that go down to the object
Modules declare permission keys. Roles are sets of keys, bound at workspace, project or object level. Guests see exactly the projects you named and nothing else.
One search across everything
Command-K reaches issues, messages, documents, files and people — and only ever returns what you are allowed to see.
English, German, Persian, Arabic, Turkish
Every string is translated, and the interface is built with logical properties, so right-to-left is a real layout rather than a mirrored afterthought.
Notifications you can actually tune
Per event type, per channel: in-app, push or email. Mentions, assignments and watches follow their own rules. Web push works on the phone, including iOS.
A public API, not an afterthought
Every screen is built on the same REST API you get, described by OpenAPI 3.1, with scoped API keys you issue and revoke yourself. Outgoing webhooks are on the roadmap.
An activity log under everything
Each object carries an append-only history. It powers the timeline you read, the feeds you follow and the audit log an auditor asks for.
Modules own their data
Each module holds its own Postgres schema, with row-level security on its tenant tables — most of them today, and the migrations name the rest. One module cannot read another’s tables — it has to ask through a contract.
Installs like an app
A progressive web app: install it from the browser, keep it in the dock, get badge counts and push, and read recent work when the train goes into a tunnel.
Yours to audit
Every line that touches your data is public. Sessions, passkeys, roles and permission bindings, encrypted per-workspace secrets — all of it readable before you trust it. Sign-in with Google, GitHub or Microsoft, and single sign-on over OIDC or SAML, are on the roadmap.
Read the code that holds your data.
16 public repositories — eight services and libraries, eight modules — in an organisation called KernAIO, AIO for all in one, which is the whole idea. The framework you build modules against is Apache-2.0; the product is AGPL-3.0. Not a source-available licence, not an open core with the useful half missing: the product you run is the code you can read.
- KernAIO/appInstall, documentation, and the workspace that links the restShell· 197 commits
- KernAIO/shellEvery screen people actually useSvelte· 223 commits
- KernAIO/coreAccounts, workspaces, roles, permissions, notifications, files, searchTypeScript· 105 commits
- KernAIO/chatConversations, and the connection that keeps everything liveTypeScript· 46 commits
- KernAIO/mailEmail leaving Kern: providers, queue, delivery log and bouncesTypeScript· 51 commits
- KernAIO/collabDocuments several people edit at the same timeTypeScript· 45 commits
- KernAIO/kernelThe libraries every service and module is built onTypeScript· 136 commits
- KernAIO/docsThe documentation siteAstro· 72 commits
- KernAIO/module-*Eight more, one per module — tracker, chat, quire, hr, mail, billing, inventory, and the Apache-2.0 template you start your own fromSee them all
The ones people ask first.
Is self-hosting a limited version?
No. Self-hosted Kern is the whole product — every module Kern ships, every feature in them, unlimited people, and nothing held back for a paid tier. The cloud is the same code; you pay us for the running of it, not for the software.
Which modules can I actually use today?
Six of them: issues and projects, chat, documents, mail, HR and inventory. Drive, calendar, recruiting, CRM, automation, calls and the AI assistant are on the roadmap for after v1.0, and the features page marks every module with which it is — and says, under each one, what it does not do yet. Kern is pre-1.0 and we would rather you chose it knowing that.
What does the licence mean for my company?
Run Kern for your own company however you like — internally, modified, forever, at no cost. The product is AGPL-3.0, which asks something of you only if you offer a modified Kern to other people over a network: then you publish your changes. Using Kern internally is not that. The framework you build modules against is Apache-2.0, so a module you write stays yours.
Can I move from the cloud to my own server later?
Eventually yes, and we would rather tell you now what it takes than after you signed up. The structural half is real: Kern is AGPL-3.0, the build we run is the build on GitHub, and installing the same version on your own server is one command. The convenient half is not built — there is no importer, so you cannot yet hand a Kern archive to another Kern and have it unpack. Getting your data out today means the public API and a script, plus asking us for what that misses. The cloud page sets out exactly which parts exist.
Do I have to use every module?
No. A workspace switches any module off, and it disappears — no navigation, no routes, no notifications, no jobs. Plenty of teams run Kern as an issue tracker with chat and nothing else.
How is this different from running four separate tools?
The links between the tools stop being copy-paste. An issue can have its own channel today; turning a message into an issue with its thread attached is on the roadmap. Underneath, there is one search, one permission model, one login and one inbox across every module — which is the part an integration can never give you.
What do I need to self-host it?
Docker 24 or newer on x86-64 Linux, 4 GB of RAM and a domain name. One command brings up the whole stack behind Caddy with automatic HTTPS. Upgrades and backups are one command each.
Where does my data go if I use the cloud?
Into a Postgres database and object storage we run in Germany, at Hetzner in Nuremberg, and nowhere else. We do not sell it, mine it or train on it. Three companies touch it — Hetzner for the servers and the files, Stripe for taking payment, Cloudflare for carrying the traffic — and the subprocessors page names them. There is no email delivery provider on that list because Kern Cloud does not send email yet; one will be named there before it does.
Can I build my own module?
Yes, and it will not be a second-class citizen. The modules we ship are written against the same public interfaces you get: a Postgres schema of your own, an API mounted beside ours, screens in the app shell, permission keys, jobs, search indexers and automation actions.
Start where it suits you
Sign up and have a workspace in a minute, or put it on your own server and keep every byte. Same product either way.
curl -fsSL https://get.kernaio.com | bash