I rewrote my encrypted form tool because I was tired of Cloudflare owning my setup

Source: Dev.to

Overview

formseal-embed is a drop‑in utility for client‑side encrypted contact forms. You drop it in, it encrypts submissions in the browser before they’re sent, and your backend receives ciphertext it can decrypt on its own terms.

The original version worked, but it was a house of cards: every time I touched it I was thinking about Cloudflare (KV, Workers, the challenge/verify pipeline). One config change upstream and everything downstream quietly broke. I started over, asking myself repeatedly: does this belong here, or am I just rebuilding the thing I hated?

The only real constraint

I gave myself one rule: the tool must work with any endpoint that accepts a POST request. No assumptions about the backend, no vendor‑specific hooks, no “optimized for X.” If you have a URL, it works.

That sounds simple, but it changes everything. The embed can’t do clever backend tricks, the CLI can’t assume a platform, and every feature had to pass the test: does this break vendor agnosticism? Many ideas didn’t survive.

The embed does less than you’d expect – on purpose

My first instinct was to make the embed smart: field‑level validation, custom error messages, auto‑generated markup. But each of those decisions belongs to the developer using the tool, not to the tool itself.

So I cut it back. The embed:

• reads name attributes,
• manages button state,
• encrypts the payload,
• posts it.

That’s all it touches. You own all the HTML. It may sound limiting, but it ensures formseal-embed works with any form structure you already have.

Why the CLI is Python and not Rust or Go

I considered Rust (fast, single binary, no runtime) and Go, but kept returning to the mental image of someone running fse init for the first time on whatever machine they have, with whatever is already installed.

Python is almost certainly present, requires no build step, and introduces zero friction. For a setup CLI, that trade‑off makes sense: the tool should get out of the way.

What’s coming: fse doctor

During testing I kept hitting a small misconfiguration that broke everything silently—wrong endpoint, bad public key, etc. Debugging was miserable.

fse doctor will run after fse init and check the entire setup: config, endpoint reachability, public‑key validity, schema fields, and more. It will tell you exactly what’s broken and which command to run to fix it. It’s not released yet, but it’s in the works and feels like something that should have existed from day one.

The thing I kept having to resist

The hardest part of the rewrite wasn’t the crypto or CLI structure; it was resisting the urge to add features. Every reasonable‑looking addition pulled the tool toward being opinionated about your backend, platform, or validation logic.

Vendor agnosticism isn’t a feature you add; it’s a constraint you enforce by saying no to many reasonable ideas.

Come take a look

The package is @formseal/embed on npm. Source is at .

If you have thoughts on what fse doctor should check, what the CLI is missing, or just want to poke around the encryption pipeline, issues and PRs are open. I’d love to hear what others think is worth validating before a form goes live.

Have you dealt with vendor‑lock problems with third‑party form tools? Did you work around it or just accept it and move on? I’m genuinely curious.