kysigned ships two ways. Both produce signatures with the same
cryptographic guarantees and the same DKIM-backed signing records.
The only thing that changes is whose name is on the door.
For signers & small teams
kysigned.com
Start sending documents in 30 seconds. We run the service, you pay per document.
Sign in with a passkey or an email link, no app to install
Prepaid credits, paid by card (Stripe is the processor)
Deploy the open-source repo on run402 and put your brand on top. White-label, embed, resell.
Your domain, your logo, your billing model
Same signing flow, same signing records
Apache 2.0 license: commercial use OK, no royalties
Deployed by an AI coding agent in minutes
Both run on the same platform. kysigned.com is just
our deployment of the open-source repo, running on
run402, the same
developer platform that powers managed email, the database, and
storage for every kysigned instance. Forking the repo
doesn’t mean wrangling AWS, ECR, or your own SES reputation.
It means standing up your own kysigned the way we did, on infra
that’s already production-grade.
What’s the same on both
The signing flow. Signers forward the signing email
back with “I sign this document”, and their email
provider’s DKIM signature becomes the cryptographic proof.
Identical on every instance.
The signing record. Every kysigned instance (ours,
yours, anyone’s) produces the same self-contained
signing record PDF: the document, each signer’s DKIM-signed email, the
timestamp proofs, and the DKIM keys.
The verification page. Drop any signing record PDF into any
kysigned /verify page and it works. The check
runs entirely in your browser, offline, with no instance needed.
The trust model. Trust comes from DKIM (the
signature your own email provider already puts on your mail) plus
the public key archives, independent timestamps, and the maths. kysigned
itself isn’t part of it.
When to use which
Use kysigned.com if you’re a person or small team
who wants to send NDAs, contracts, or approvals without thinking about
infrastructure. Sign in, upload, send, done.
Run your own if you’re embedding signing into
a product you offer, putting your own brand on the experience, or
building agentic workflows where your AI handles document signing for
end customers. The repo + run402 means you’re standing up a
complete signing platform in an afternoon, not a quarter.
Have an AI agent? Even faster.
Standing up your own instance is a coding-agent job. Paste this into Claude, Cursor, or any coding agent:
Deploy kysigned (the Apache-2.0-licensed e-signature template at
github.com/kychee-com/kysigned) on run402 for me, using the run402 SDK and
my config. Set up my custom domain and send a test document to confirm it works.
Once your instance is running, an AI agent can drive the signing for you. The
kysigned MCP server gives an agent five operations against your own instance:
send a document, check its status, list your documents, send reminders, and void.
It ships alongside the open-source repo.
Using the kysigned MCP server for my instance, send the NDA at
./contract.pdf to alice@example.com for signing.
