The Aegis website is what trust looks like in HTML
Beem Development turns a public landing page into part of the security story, using React, Vike, and a tightly controlled SSR pipeline to keep the site fast, explicit, and easy to verify.
Hey! Thanks for considering contributing to Aegis. But are you sure you're not running into our password reminder? We implemented a password reminder to decrease the chances of people forgetting their passwords. If someone forgets their password, they may lose access to their vault. You can either type in your password once (recommended), or disable the password reminder in the settings.
- The website is built like an extension of Aegis's privacy promise, so the stack, copy, and routing all point toward trust rather than spectacle.
- Vike and Express give the team precise control over server-rendered HTML without forcing them into a heavyweight platform.
- The review carousel is a good example of disciplined interactivity, because it uses client-only hydration and CSS animation instead of extra runtime machinery.
- The repo's structure keeps content, components, and rendering concerns separate, which makes the site easier to maintain than many project homepages.
Most open-source project sites are brochureware. This one behaves more like a trust layer, where every technical choice reinforces the same message: the app is private, the code is inspectable, and the public face should be just as careful as the vault behind it.
A website that mirrors its product
The site belongs to Aegis Authenticator, the open-source 2FA app from Beem Development. That matters because the product itself sells caution, backups, and user control. The website follows the same instinct, starting with a privacy policy that says Aegis Authenticator does not collect any data from your device.
That same tone shows up in support. When a user asked about biometric unlock, maintainer Michael Schattgen answered with a reminder about the app's password reminder, because a forgotten password can mean a locked vault.
The answer is practical, not polished. That's useful, because the site itself avoids the usual fluffy product language and keeps pushing readers back to verifiable details: features, FAQ entries, and the source code.
The stack is the point
Under the hood, the website uses React 18, Vike, Express, Tailwind, and TypeScript. That combination sits in a useful middle ground. It is more hands-on than Next.js, less platform-shaped than GitBook, and far more custom than a plain static page.
The interesting part is the separation of labor. +onRenderHtml.tsx assembles the initial document, +onRenderClient.tsx wakes it up, and the data files feed the UI without stuffing content into components. The result is a page that behaves like a real web app without making the homepage feel heavy.
The review row goes one step further. Its endless motion is CSS-only, so the carousel stays smooth and the browser can pause it on hover without a scroll listener or animation framework.
keyframes: {
loop: {
from: { transform: 'translateX(0)' },
to: { transform: 'translateX(calc(-50% - var(--gap)/2))' },
},
}How this compares
| Option | Best at | Trade-off |
|---|---|---|
| GitHub Pages plus Jekyll, Hugo, or Eleventy | Fast static publishing and low hosting overhead | Less control over SSR, metadata wiring, and custom runtime behavior |
| Docusaurus or GitBook | Docs workflows, navigation, and out-of-the-box content structure | More opinionated and more shaped by the platform than by the project |
| beemdevelopment/website | Precise SSR, custom metadata, and data-driven components | You maintain a real Node stack and the rendering pipeline yourself |
For a security product, the compromise is sensible. The site gets the control it needs for SEO, metadata, and hydration, but it stops well short of becoming a mini platform.
What the repository structure buys them
The directory layout looks boring in the best way. /pages handles route-specific content, /components holds reusable UI, /data keeps copy separate from presentation, and server/index.ts acts as the bridge into Vike's render cycle. That separation makes the homepage, privacy policy, and support pages feel like pieces of one system instead of one-off React screens.
That is the real differentiator here. The site is not trying to be clever. It is trying to be legible, fast, and hard to misread, which is exactly what a security app's front door should be.
