Quantor
Security · 10 min read

How we sign every prod deploy with Ed25519 — and why your bot doesn't

Pavel · Solo founder · · ← All posts

Open https://api.quantorsaas.app/api/v1/identity in a new tab. You'll see a JSON response with three things: a service name, a canonical build manifest, and a base64-encoded signature. Now fetch /.well-known/quantor-pubkey — that's our public key. Run one openssl command and you've just proved that the code running on our server right now is exactly the code we committed to the repository. Not trusted — verified.

Approximately zero other crypto-bot SaaS lets you do that. This post explains why we built it, what it catches, what it doesn't, and the exact recipe to run the verification yourself.

The 2022 thing that made trust insufficient

In late 2022, 3Commas — at the time the most popular crypto-bot SaaS in the category — leaked API keys for a large number of its users. The leak went through their infrastructure, not the exchange. Money moved through unauthorised withdrawals. 3Commas compensated a portion of the losses, but only a portion.

What was striking in the aftermath was not the breach itself — breaches happen — but the realisation that nobody could verify what was actually running on 3Commas's servers. The product was a black box. You could see what they claimed they were doing. You could not see what they were actually doing. The whole category was built on "trust us, we're careful", and there was no cryptographic artifact a normal user could check on their own.

The category sold one thing — automated execution — and asked you to trust an opaque pipeline to do it. That's the contract every bot-SaaS user signed without realising.

We started building Quantor with a single constraint: every claim we make about the running build must be independently verifiable by the user, with off-the-shelf tools, in under a minute. The mechanism we picked is Ed25519 signed builds. Same idea as code signing for desktop apps, applied to the running bytes of a SaaS service.

What Ed25519 actually does (15-second primer)

Ed25519 is a public-key signature scheme. You generate a keypair once. The private key stays on your machine and is used to sign messages. The public key is published openly and is used by anyone to verify those signatures. You can verify; you can't forge.

Three concrete properties we care about:

  • Compact. 64-byte signatures, 32-byte keys. Fits in an HTTP header or env var without ceremony.
  • Deterministic. Sign the same message twice with the same key, you get the same signature. Easier to test.
  • Fast. Verify in microseconds. Means we can verify our own build hourly without burning CPU.

The math is publicly documented (RFC 8032). The implementations we use are in the JDK and in OpenSSL, both audited extensively. We didn't roll our own crypto.

What we actually sign

Every Quantor production deploy has three components: quantor-api (the Spring Boot REST API), quantor-worker (the Java scheduled-job worker), and quantor-site (the Express static-site front-end). All three are signed independently before deploy. The thing we sign is a tiny canonical JSON manifest: 

{
  "service": "quantor-api",
  "commit": "37cb5a59ce02dea0487758440adac710e05c59d2",
  "image":  "sha256:ad09576d90271ecb53f439d7e856660f39619c35ac782cb86ad2f8500d7316eb",
  "builtAt": "2026-05-09T16:20:25Z"
}

Four fields. service identifies which of the three containers this is. commit is the git SHA of the source. image is the Docker image digest produced by the build. builtAt is the exact timestamp the manifest was signed. Together they uniquely fingerprint one specific deploy.

The deploy script computes this manifest, signs the raw UTF-8 bytes with our offline private key, and writes both the manifest and the base64-encoded signature into the Cloud Run revision's environment variables: QUANTOR_BUILD_MANIFEST and QUANTOR_BUILD_SIGNATURE. The api / worker / site read those env vars at startup and expose them on their identity endpoints. That's the entire mechanism on the deploy side.

Where the key lives

The private key file is at ~/.quantor-signing/quantor-priv.pem on Pavel's deploying machine. It never enters version control, never ships in a Docker image, never sits in Secret Manager, never lands on any Cloud Run instance. It exists in exactly one place outside of Pavel's head: a local PEM file on a single laptop.

The corresponding public key is committed in three places so any consumer can verify against it:

  • deploy/identity/quantor-pubkey.pem — the deploy script's self-verify step reads this; if the freshly-signed manifest doesn't verify against this file, the deploy aborts. This is how a typo or wrong key gets caught at deploy time, not at "user files a support ticket" time.
  • quantor-api/src/main/resources/quantor-pubkey.pem — bundled into the api jar. BuildSignatureVerifier loads it at startup and confirms that the running env-var signature matches.
  • https://quantorsaas.app/.well-known/quantor-pubkey — served publicly so anyone can fetch it and verify without downloading our source code.

All three copies must change in lockstep when the key rotates. Since rotation is not routine, this is a controlled event documented in docs/security/build-signing-runbook.md.

Three ways to verify, from easy to engineer-y

1. The browser way (no tools needed)

Open quantorsaas.app/security. There's a "🛰️ Live build identity" card near the top. It fetches /_identity.json on page load and shows the current verified state, plus the commit, image digest, builtAt timestamp, and the public-key fingerprint. If it says "✓ verified", the browser already did the verification on your behalf using the pubkey shipped in our HTML / JS bundle.

Trust level: same as trusting your browser and our HTML. Good enough for a quick sanity check. Not adversarial-proof.

2. The curl + openssl way (~30 seconds)

This is the adversarial-proof version. You fetch the public key from our well-known URL, you fetch the manifest and signature from our api, and you run openssl locally to verify. If you don't trust our JS, this is the path: 

# 1. Fetch the public key (also committed in our public repo).
curl -s https://quantorsaas.app/.well-known/quantor-pubkey > pub.pem

# 2. Fetch the live build manifest + signature from the API.
curl -s https://api.quantorsaas.app/api/v1/identity > id.json
jq -r '.manifest'  id.json > manifest
jq -r '.signature' id.json | base64 -d > sig

# 3. Verify.
openssl pkeyutl -verify -pubin -inkey pub.pem -rawin -in manifest -sigfile sig
# → "Signature Verified Successfully"

Three commands. Less than a minute. If you get Signature Verified Successfully, you have just cryptographically confirmed that the bytes you're talking to on api.quantorsaas.app are the bytes our deploy script signed. If you get any other output, something is off and we want to hear about it.

3. The continuous-monitoring way (Pulse probe)

Inside Quantor's admin we run a synthetic probe called Pulse. One of its 13 steps is obs.build-signed — it does the same openssl-equivalent check every hour against the running api, and compares the pubkey fingerprint against the one committed in the repo. If anything drifts, the probe goes red and we get a Telegram alert.

We didn't build Pulse for users — we built it for ourselves, to catch silent supply-chain drift between deploys. But it means the verification is happening every hour whether anyone is looking or not. The cached state is visible at /security for any reader.

What this catches

The scenarios this closes
  • An attacker who compromises Cloud Run or our build pipeline and tries to push a malicious image — the signed manifest won't match the running image digest. Pulse goes red. We see the alert before users see the consequence.
  • A contractor with temporary deploy rights who later tries to push a private build "in our name" — they don't have the offline key. Their deploy will run with an unsigned manifest, the identity endpoint will return verified=false, and the discrepancy is public.
  • A future me, attempting in some weak moment to push a hotfix without the signing key from a borrowed machine — the deploy script aborts at the self-verify step before the container ever starts. There's no path to "I'll sign it later" — the deploy is signed or it's blocked.
  • A bad actor at GCP itself with access to our project's revision history, replaying an older revision with malicious env vars — the env vars are part of the revision; tampering changes the manifest, breaks the signature.

What this does NOT catch

Threats this mechanism does not address
  • A compromise of Pavel's local machine that exfiltrates the private key. From that point forward an attacker can sign whatever they want and it will verify cleanly. Mitigation: machine hygiene + rotation procedure documented in the runbook.
  • A compromise of the source code before Pavel signs the build — i.e. a malicious commit lands on main, Pavel signs it during deploy, the signature is valid for malicious code. Mitigation: every commit is from a single author so code review is "Pavel re-reads his own diff"; honest answer is this is the weak link a public repo + multiple committers would solve.
  • A supply-chain attack on a dependency (compromised Maven artifact, npm package) that ends up in the signed image. The signature confirms the image was assembled from those dependencies — it doesn't confirm the dependencies themselves are trustworthy. Mitigation: pinned versions, dependency-check scans, no transitive freedom in critical paths.
  • A flaw in Ed25519 itself or in OpenSSL / the JDK's implementation. The attack surface here is the entire history of public cryptanalysis on Ed25519, which is well-established. Not a special Quantor risk.

The honest framing is: build signing closes the deployment-and- operations attack surface. It doesn't replace code review, dependency pinning, or operational discipline. It just makes those failures visible to outside observers, not hidden behind opaque infrastructure.

The unsigned-deploy story

One detail worth pulling out: if the signing key is missing on the deploying machine (e.g. a contractor's laptop, or CI without secrets configured), the deploy script does not abort. It proceeds with empty QUANTOR_BUILD_MANIFEST and QUANTOR_BUILD_SIGNATURE env vars, and the api reports verified=false at /api/v1/identity. The Pulse probe sees this and emits a SKIP (not a FAIL) — the build is "unsigned dev deploy" rather than "tampered prod deploy".

We made this choice deliberately. A hard-abort on missing key would mean Pavel can never push a quick fix from a different machine. The soft-fallback means the system stays operable while still publicly signalling that the running build is not cryptographically certified. In prod this state is treated as an alert; in staging it's normal.

Why almost no other bot does this

A few practical reasons:

  • Cost. You have to write a deploy-script signing step, a runtime verifier, a key-rotation runbook, an identity endpoint, monitoring around the verifier. That's maybe a week of engineering for a feature that does not show up in any A/B test.
  • Operational discipline. The key has to actually stay offline. If it leaks once, the entire mechanism is worthless. Most teams won't accept the constraint.
  • It commits you to honest disclosure. If your identity endpoint ever says verified=false in prod, users see it. There's no covering it up. Most teams prefer the opacity.

Quantor is small enough — one person, one key, one repo, one region — that we can take on all three. Larger teams typically can't. That's the actual moat: not the cryptography, but the operational tradeoff that a single founder will accept and a larger org won't.

Try it now

You don't need an account to verify. You don't need to pay us. You don't even need to like us. The endpoint is open: 

curl -s https://api.quantorsaas.app/api/v1/identity | jq .verified
# → true

If that returns true, every byte of our running api was signed by a key that physically lives on a single offline machine. If it returns false, we have either deployed unsigned (and the page at /status will say so) or something is wrong and we're already chasing it.

Either way, you didn't have to trust us. You just verified us.

For the operational details — rotation, threat model, Pulse probe logic — see the Security page. For the deploy script itself, see deploy/gcp/_sign-build-manifest.sh in the public repo. Questions, criticism, or breakage reports go to quantorsaas@gmail.com. The author of this post (Pavel, solo founder) reads everything personally.