PROMARIS

Technology

Built in Rust.

No WordPress. No PHP. No JavaScript framework. This website is — from the HTTP server to the animation in the browser — written entirely in Rust, compiled type-safe and delivered as WebAssembly.

Language breakdown

Measured during the build from our own source tree — including this page.

Rust62.9%
TOML26.8%
SCSS10.3%

What is not in it

0lines of hand-written HTML
0lines of JavaScript
0lines of PHP

The HTML is generated at runtime from Rust code. The only JavaScript is the loader bridge generated by the Rust→WebAssembly toolchain — we do not write a single line of it ourselves.

Crates in use

Pointing at a crate reveals the detailed explanation. A click opens it on crates.io — Rust’s official package registry, including source code and documentation. Reading up on it is expressly encouraged.

  • leptosReactive fullstack UI (SSR + WASM)Leptos is the fullstack framework this website is built on. The interface is described as reactive components in Rust and is both rendered on the server (for a fast initial delivery and for search engines) and executed in the browser as WebAssembly. The same Rust codebase thus runs on both sides — entirely without a separate JavaScript frontend.
  • leptos_routerRouting between pagesThe Leptos router determines which page belongs to which address. Page changes happen in the browser without a full reload, so navigation stays fluid — while the server can additionally deliver every address directly.
  • leptos_metaTitle and meta tags in the <head>Manages the entries in the document’s <head>: page title, meta description and other header data. This gives every page the right information for the browser tab, search engines and link previews.
  • serdeSerialization of the contentserde is the standard tool in Rust for translating data structures between Rust types and formats such as TOML. Here it turns the content stored as text into type-safe Rust objects — and back again when needed.
  • serde_jsonJSON serializationserde_json is serde’s JSON implementation. The messages of the encrypted API are transported as JSON; this crate converts them between Rust structures and JSON and back.
  • ml-kemPost-quantum key encapsulation (ML-KEM-1024, FIPS 203)ml-kem (RustCrypto) implements ML-KEM-1024 according to FIPS 203 — the post-quantum key encapsulation method standardized by the US standards body NIST. With it, browser and server agree on a shared secret that is intended to remain secure even against future quantum computers. It is the basis of our additionally encrypted API.
  • kemTrait abstraction for key encapsulation (KEM)The lean trait abstraction (Encapsulate/Decapsulate) through which we address ml-kem — it keeps the crypto code cleanly interchangeable.
  • chacha20poly1305Authenticated encryption (AEAD)ChaCha20-Poly1305 is a modern AEAD method (authenticated encryption). It encrypts every API message and at the same time ensures that it cannot be altered unnoticed in transit.
  • hkdfKey derivation (HKDF)HKDF derives a clean, purpose-bound session key from the raw ML-KEM secret (RFC 5869) — instead of using the secret directly. This provides domain separation and a clear audit trail.
  • sha2SHA-512 hashsha2 provides the SHA-512 hash function on which the key derivation of the encrypted API (HKDF-SHA512) is based.
  • rand_coreCryptographic randomness (OsRng)rand_core provides the cryptographically secure source of randomness (OsRng). In the browser, the randomness comes from the Web Crypto API — the basis for keys and nonces.
  • ed25519-dalekServer key signature (Ed25519)ed25519-dalek certifies the server's post-quantum key. Without that signature an intermediary — a CDN, a reverse proxy — could slip in a key of its own and read everything. Your browser verifies the signature against a verification key compiled into the program before it encrypts anything; if the check fails it stops. There is no fallback to “unsigned after all”.
  • rand_chachaDeterministic CSPRNG (ChaCha20)rand_chacha produces a cryptographically secure random stream using the ChaCha20 construction — deliberately deterministic here: from a single stored starting value it always derives the same ML-KEM key pair for the server. That is the only reason the key your browser fetches still fits the instance that later decrypts your request. Genuine randomness — nonces and the short-lived keys of your session — comes from rand_core instead.
  • base64Base64 encodingbase64 encodes the binary crypto building blocks (key, ciphertext, nonce) as text so they can be conveniently transmitted as JSON.
  • leptos_wasiLeptos SSR as a wasi:http componentleptos_wasi connects Leptos’s server-side rendering and server functions to the wasi:http interface. Instead of a classic HTTP server, the server side therefore runs as a WebAssembly component in a ring-free WASI runtime (wasmtime) — frontend and backend are a single Rust program, both as WebAssembly.
  • wasiWASI interfaces (wasi:http, randomness)The wasi bindings provide the standardized WASI interfaces through which the component talks to its environment — incoming HTTP requests (wasi:http), randomness (wasi:random) and file access. TLS and networking are handled by the runtime, not the application.
  • any_spawnerSingle-thread future executorany_spawner provides the future executor that processes the component’s asynchronous render work. WASI is (still) single-threaded, hence a lean, cooperative executor instead of a multi-threaded runtime.
  • wakiHTTP client over wasi:httpwaki is the HTTP client of the server side — implemented via wasi:http rather than a dedicated TLS library. It thus files a request from the contact form as a ticket in the ticketing system, while encryption of the connection rests with the WASI runtime.
  • tomlReading content as codeTOML is a lean, highly readable text format. The content of this website is stored as TOML files; this crate reads them in. Texts can thus be changed without touching program code — content as code.
  • anyhowError handlinganyhow simplifies error handling in Rust. Different error sources are combined into a single unified type, which keeps the server code clear and robust.
  • httpHTTP base types (status/headers)http provides the fundamental HTTP types (status codes, headers, methods) as a common language between the application and the wasi:http interface.
  • bytesEfficient byte buffersbytes provides efficient, shareable byte buffers — here for the bodies of incoming requests and outgoing responses of the WebAssembly component.
  • gloo-netHTTP requests in the browsergloo-net makes HTTP requests directly from the WebAssembly code. With it, the browser fetches the server’s public key and sends the encrypted API requests.
  • console_error_panic_hookPanics in the browser consoleA small helper for the WebAssembly side: if an unexpected error (panic) occurs in the browser code, it is printed intelligibly to the developer console instead of vanishing silently — which makes troubleshooting considerably easier.
  • wasm-bindgenBridge Rust ↔ browserwasm-bindgen bridges the WebAssembly written in Rust and the browser’s functions. It enables Rust code to call browser interfaces and vice versa — the basis for the program running in the browser at all.
  • js-sysBridge Rust ↔ JavaScriptjs-sys maps JavaScript's built-in types — arrays, objects, promises — into Rust. Through it the WebAssembly code reaches what the browser brings along by itself: an invoice you drop into the checking tool arrives in the Rust code as a byte array across exactly this bridge.
  • web-sysBrowser APIs (canvas and more)web-sys provides the browser’s programming interfaces as Rust functions — such as window, document or canvas. With it, Rust draws, among other things, the animated shard field directly in the browser.

Encrypted API (post-quantum)

Classical web encryption (RSA, elliptic curves) is considered secure today — until powerful quantum computers break it. Anyone already storing intercepted traffic today could then decrypt it retroactively (“harvest now, decrypt later”). That is why we additionally secure the connection between your browser and our server with a method designed to withstand even quantum computers.

We use ML-KEM-1024 (FIPS 203) — the post-quantum key-exchange method standardized by the US standards authority NIST. This layer sits additionally on top of the already active TLS encryption: a double safety net, not a replacement.

  1. Key encapsulation. Browser and server agree on a shared secret via ML-KEM-1024 — secure against quantum computers as well, by today’s standards.
  2. Key derivation. From this secret, a fresh session key is derived using HKDF-SHA512.
  3. Encryption. Every message is authenticated-encrypted with ChaCha20-Poly1305. The client key is firmly bound to the content — so the response cannot be secretly redirected.

The following handshake is running live in your browser right now:

Channel is being established…

How this page reached you

This page did not come into being somewhere in a cloud. It is served from our own office — by a Rust gateway on real hardware. The path there is short and real: your browser lands directly on one of three internet anchors (code names Caraxes · Meleys · Sunfyre), which passes the request on to our office gateway Balerion. No CDN, no third-party edge service in between — the anchors run nothing but our own TCP forwarder, which passes the connection on without opening it. That is where the path ends: Balerion is at the same time the WASI host that runs this WebAssembly component — it rendered precisely this page.

  1. Endpointyour browser
  2. one of three anchorsCaraxes · Meleys · Sunfyre
  3. Office gateway · runs this pageBalerion WASI-Host

Establishing connection… Without JavaScript, the path above remains as a list — correct, just without live figures.

How it all works together

  1. Server. The same Rust codebase runs as a WASI WebAssembly component in the wasmtime runtime (target wasm32-wasip2) and pre-renders every page (SSR) — no classic server process, no C crypto library.
  2. Content. Texts exist as code and are loaded into an in-memory database at startup.
  3. Browser. The same Rust program — compiled to WebAssembly (target wasm32-unknown-unknown) — continues to run in the browser and takes over the page (hydration). Page changes fade smoothly via view transitions, entirely without reloading.
  4. Graphics. Rust draws the shard field directly onto a canvas — no image, no video.
  5. Delivery. Every build produces a new WebAssembly component. It runs on our own Rust gateway on real hardware in the office — and that is the only place rendering happens. There is no CDN and no edge service in front of it; three internet anchors operated by us pass the traffic through without decrypting it.

What the build costs

Measured while building this very component — not estimated and not carried over from a test run.

Metrics are only available in the deployed component.

How fast it loaded for you

No lab, no average value: these three figures were measured by your own browser.

…

The HTML arrives fully rendered from the server — readable before the WebAssembly has even loaded. That is why the page stands even if the WASM never arrives.

Building a website in Rust is unusual — and that is precisely the point. Anyone who implements a homepage this way will build your systems with the same care. If you want technology at this level for your own organization: Talk to us

Back to top