build 3.0.0 · aes-256-gcm / post-quantum · eu/de · ram only

ParaRules

What Paramant stands for, and how we build it.

These are the rules. Not marketing copy. They are the constraints we hold ourselves to, in the product and in the code. If we ever break one, hold us to it.

What we guarantee

1 · We never had it

Files are encrypted in your browser before they reach us. The relay holds only ciphertext, in RAM, and burns it on read. We can’t read it, can’t leak it, and can’t be compelled to hand over what we never had.

2 · Your browser talks only to us

No third-party requests. No Google fonts, no CDN, no analytics, no pixels, no embedded widgets. Open your network inspector on any page: every request goes to paramant.app and nowhere else.

3 · No surveillance

No tracking cookies, no fingerprinting, no ad tech. One functional session cookie after you sign in. That is the entire list.

4 · You own your keys

Keys are generated on your device and never leave it. Your passkey’s private key is yours alone. We only ever see the public half.

5 · EU soil, EU law

Hosted in Germany, owned top to bottom in the EU. No US CLOUD Act reach over your data.

6 · Quantum-ready by default

FIPS 203/204 (ML-KEM and ML-DSA) today, not “soon”. Harvest-now-decrypt-later is already happening; we encrypt for the decade, not the demo.

7 · Honest by design

No dark patterns. When something fails, we tell you what failed and how to recover. Never a vague or misleading message to keep the UI looking tidy.

8 · Verifiable, not trust-me

Open-core you can run yourself, a public Certificate Transparency log, and a relay that proves what it does. You don’t have to trust us. You can check it.

9 · Only what’s required

An email to hold your account. No phone number, no IP logging beyond transit. Minimalism as a security property: data we don’t hold can’t be breached, subpoenaed, or sold.

How we build it

The same rules bind how we ship. The promises above are only credible if the engineering behind them is disciplined.

We never deploy blind

Every change to production is preceded by a backup and a tagged rollback point, and verified on the live site afterwards. If we can’t prove it works on the running service, it isn’t done.

Reversible by default

Every deploy has a one-step rollback (a tagged image, a backup archive) captured before the change, not improvised after something breaks.

The sign-in path is sacred

Authentication is never deployed casually. A rollback handle first, then every sign-in path is checked before and after the change. We would rather be slow than lock you out.

We don’t overwrite each other’s work

Before any file is touched, we verify that what is live still matches what we expect. Surprises get flagged, not steamrolled.

Honest errors over convenient lies

The same rule as the product: when a deploy or a check fails, we say so plainly, in our own logs and reports too, rather than paper over it.