DocKosha Is Now Fully Open Source, Down to the Engine That Watermarks Your PDF

When you send someone a link to your pitch deck, a contract or your company's financials, you are basically handing a tool something you really don't want ending up anywhere else. So how do you actually know what that tool does with your file once it has it? With most document sharing products you can't know, because what you can read is the marketing and a pricing page, while the code that actually touches your document stays private.

That is why I made DocKosha fully open source. DocKosha is a product I built for secure document sharing and virtual data rooms, and now both parts of it are public on GitHub under the AGPL license. One part is the app itself, and the other is DocYantra, the engine that handles PDF and Office processing plus the watermark. I wrote the official announcement on the DocKosha blog, but here I want to go through what fully open source really means in this case, what you can do with the product, what you need if you want to host it yourself, and why I'd call it the best open source DocSend alternative you can pick right now.

What "fully open source" means for DocKosha

So why do I keep saying fully? Back in September I opened up the DocKosha application, but DocYantra stayed closed. And DocYantra is the part that really works on your file, because the PDF and Office processing and the watermarking all happen inside it. So you could read the app code, but the most sensitive piece was still a black box you had to trust, and to me that defeats the purpose when the whole idea is letting you check how your documents are handled.

Now both repositories are public. The app is DocKosha, built with Next.js, and the document engine is DocYantra. Both are under AGPL-3.0-or-later.

If you haven't come across AGPL before, it is what's called a copyleft license. Basically, you are allowed to use, modify and run the code. The catch is that if you modify it and other people use your modified version over a network, you have to share your version's source code with them too.

There is also just one public edition of the application. I don't keep a private enterprise build with extra features that only appear after you get on a sales call, so the code you see on GitHub is the product. If a company doesn't want to work under AGPL, they can sign a separate agreement for an enterprise license, and the commercial licensing terms are in the repo.

Why the security features had to be readable

Document sharing tools are usually sold in plans, and that's normal. But it does mean that for things like who is allowed to open a link, or whether a watermark is actually on the file, you end up trusting a plan table. For example, DocSend is a closed product, so there is no way to read how it handles your document, and the features you get depend on which plan you are paying for. If keeping documents safe is the whole reason a product exists, I think you should be able to check the parts that matter most to you.

So with DocKosha I wanted the answer to live in the code. Say you want to know how the NDA gate works, or what really happens when you revoke a link. Then the repository is right there, so you read the code yourself, and nobody's word has to be taken for it, mine or the pricing page's.

DocKosha Cloud follows the same idea in how its plans are set up, because paid plans all come with full room controls from the first day, and the difference between them is mostly storage and price.

What you can actually do with DocKosha

A list of features doesn't tell you much by itself, so let's walk through a case. Imagine you are raising a round as a founder, and a few investors need to see your deck and your financials. You upload both files, make a link, and then the real work is deciding who gets in.

You can protect the link with a password, or ask for a one-time code sent to the viewer's email. You can also allow or block particular people by their email address, give the link an expiry date, and if you have second thoughts later, you can revoke it.

For the more sensitive files you can add an NDA gate, so nothing opens until the investor has accepted the NDA, and you can switch on watermarking. On DocKosha Cloud the watermarking happens on the server, so the mark is burned into the actual PDF the viewer receives. That means it lives inside the file, and the browser isn't painting it over the page afterwards.

Then there is the case where some text in a document should never be seen at all, for example a customer's name inside a contract. Redaction in DocKosha is permanent and goes through DocYantra, which means the text is really removed from the PDF, and you don't end up with a black rectangle that still has the words sitting underneath.

Once you have more than a couple of files, you can group them into a virtual data room. Think of a data room as one shared space for a deal or a funding round, with its own access rules, so every document for that deal sits in one spot. You can reuse a room across investor, sell-side, buy-side and due diligence work, which saves you from sending the same people ten different links.

Once the link is out, the next thing you want is to know what people did with it. The analytics show views, how long someone stayed on each page, and downloads. So for example you might notice an investor spent a good while on the financials and never really looked at the team page. My aim with the analytics was to give you that kind of picture without collecting more about the viewer than it needs to.

A few more things help once a deal is moving. Viewers can comment and ask questions through Q&A. With version history you can swap in a new version of a file and the links people already have still work. And there is an audit log that only the owner can see. It records things like uploads, renames, changes to links and updates to access, so later you can look back at what changed and when.

Why I'd call DocKosha the best open source DocSend alternative

DocSend is the tool most people compare against, and as I said, it is closed. The open source option people usually bring up is Papermark, and to be fair, Papermark's README calls it the open source DocSend alternative. But Papermark's license file says anything inside the ee and app/(ee) folders is covered by a separate commercial license, and AGPLv3 applies to everything else. So one part of that product has different terms from the rest, and you would need to figure out which parts those are for whatever you want to do with it.

In DocKosha there is no enterprise folder, and one license covers the entire application. The Cloud versus self-hosted page says none of the security parts change depending on which edition you run. That means the link gates, the NDA gate, watermarking, redaction, data rooms, analytics, version history and the audit log. So that is my reason for calling DocKosha the best open source DocSend alternative: everything that protects your documents is public and covered by the same license.

Still, I think it depends on your situation. For example, if your team is happy paying for DocSend, and nobody there will ever look at the code or host anything, then the fact that DocKosha is open source probably isn't enough to make you move. It's also fair to say DocKosha is a young, small project, and if your company cares a lot about a long track record, you should weigh that.

So I think DocKosha fits best when you want to see for yourself how your documents are handled, when you want it running on your own servers, or when you are tired of paying a lot for features that are locked behind the next plan up.

What self-hosting needs, and what you take on

To run DocKosha on your own infrastructure, you need four pieces:

• a server or platform that runs Node.js 24 apps
• Supabase, which gives you Postgres and authentication
• an S3-compatible bucket where the documents are stored
• SMTP, for sending sign-in codes and notifications

DocYantra ships as versioned Rust and WebAssembly packages that run inside the app, so there is no extra conversion server to set up and you won't need a Rust toolchain. One thing to sort out before you start is that those packages are hosted on GitHub Packages. GitHub Packages wants a classic GitHub token that has read:packages access, and it wants that even though the packages are public, so you will have to create that token first.

But I want to be clear about the trade-off here. Self-hosting isn't officially supported and you do it at your own risk, which means you are the one looking after backups, security updates, monitoring, and the database, storage and email. If you ask the community for help, it's best effort and there is no SLA.

The guide also assumes you already run servers, so think of it as an operator guide and don't expect a one-command installer. All the details are in the self-hosting guide and the full walkthrough in the repo, and DocYantra has its own deployment guide as well.

How DocKosha pays its bills when the code is free

So if anyone can run the code for free, where does the money come from to keep DocKosha going? The answer is DocKosha Cloud. Running hosting, storage, email and monitoring as a managed service costs money, so Cloud does that operations work for you, and the subscriptions people pay for Cloud are what keep the project funded.

At the time I'm writing this, the pricing works like this. The Free plan is $0 a month, and you get one member, 250 MB of storage and 2 GB of monthly bandwidth. It only takes PDF uploads and the DocKosha branding stays on.

Then there are three paid plans. Essential costs $49 a month and comes with 5 GB, Plus is $199 a month for 30 GB, and Max is $779 a month for 200 GB, and if you pay annually you get 30% off. On any paid plan you can upload file types other than PDF, use a custom domain, remove the branding and get version history, and Essential has a 14-day trial that doesn't ask for a credit card.

Read it before you trust it

So back to where we started: how can you tell what a document sharing tool is doing with your file? With DocKosha the answer is that you go and read it, starting at the link gate in the app and going right down to the engine that puts the watermark on the PDF. If you are comparing DocSend alternatives, I think being able to check that yourself is the best reason to choose one, because then you aren't relying on a plan table or a sales page to tell you what's true.

If you want to try it, you can begin on the free plan, look through the code on GitHub, or host it yourself if running the infrastructure is something you are comfortable with. And if you find something broken or something that could work better, the contribution guide in the repo explains how to help.