Hypefox

How we build

Hypefox writes and runs its own platform. These are the rules every change follows, in the code and before it reaches a live server.

How a release ships

  1. Tested

    Every change passes the full test suite and the code guards on CI before it can be merged.

  2. Built and signed

    The release is built from that commit and signed with Ed25519 and ML-DSA-65.

  3. Rehearsed

    It is rolled out first on a full copy of production: applied, rebooted, rolled back and applied again.

  4. Rolled out

    On the live server each module is replaced in turn and checked before the next one goes.

  5. Rolled back if it fails

    A release that fails its health checks is undone by the server itself, back to the release that ran before.

Standards

  • Fails closed

    When a safety check cannot be answered, the answer is no. Nothing goes through on a guess, and the operator is told why.

  • Small privileged code

    The few parts that run with root rights carry out exact, narrowly checked orders. Anything that decides or remembers runs without them.

  • No known races

    A race anyone can name is a bug. It is fixed by making the paths exclusive, never by waiting a little longer.

  • Every fix leaves a test

    A fixed bug leaves a test that fails without the fix. A test that fails now and then is a bug to find, never one to run again until it passes.

  • Privacy the build enforces

    Visitor addresses are anonymised by default, and the build fails if any code records one outside the single stage allowed to.

  • Designed before built

    Storage, locking and anything with crash points is modelled in writing and reviewed before code is written.

  • Accessible by requirement

    The Velrix interface is held to WCAG 2.2 AA, and an automated scan checks every app in both the light and the dark theme.

  • Compliance in the platform

    Every module declares the personal data it processes, and disclosure requests are answered from the modules' own evidence.

  • Failure on purpose

    The platform stops a module or a host agent on a schedule, within the limits its policy sets, and keeps each recovery as evidence.

What we've built

One platform for every workload
Sites, apps, databases, mail, virtual machines and scheduled jobs share one core: one sign-in, one permission model, and limits an operator changes while it runs.
Privacy as a stage
Visitor logging is a stage of Velrix Edge, anonymised by default (IPv4 to /24, IPv6 to /48). Off records nothing, and an operator cannot loosen an owner's setting.
Errors that explain themselves
When something fails, the visitor sees a documented code and which layer failed, and the site's owner is told as it happens.

How each part works is documented at velrix.com.

Programmable edge

Every request to a site or app on Velrix passes through Velrix Edge, a chain of stages the customer sets up.

  • Stages for who gets in, rewrites and headers, the customer's own script, and the cache.
  • Each stage has its own breaker, and one that guards refuses when it trips.
  • An optional stage that trips is skipped, and the site stays up.
How a request passes Velrix Edge: through access, rules, an edge script and the cache to the app, and back through the cache, compression and the access log. A stage whose breaker is open is skipped if it is optional; a failure shows an error page with a documented code.VisitorRequestAccesswho gets inRulesrewrites, headersEdge scriptyour own codeCachefrom memoryYour site or appbehind Velrix EdgeResponseCachefrom memoryCompressbreaker open, skippedAccess loganonymisedVisitor

Module mesh

Velrix has no central server. Every part is a module with its own signed identity, in a locked-down rootless container.

  • Modules find each other on their own and agree on what each may say.
  • Every contract between them ships its own tests, which the modules keep running against each other.
  • Traffic follows the results: a module that stops answering or fails gets none until it passes again.
  • In our failure tests, a module killed outright is back in about 0.2 seconds and the mesh is whole in under 0.4.

Velrix OS

Velrix runs on its own operating system, one signed AlmaLinux image.

  • Installed with Secure Boot on a local disk, or booted over the network with no disk at all.
  • An update swaps the whole image, and a server that fails to boot it goes back by itself.
  • A server with no internet connection updates from a USB stick, applied only with a hardware key enrolled to that server.
  • The module mesh and every project's network span the servers as Geneve overlays, so calls move to a copy on another server within seconds.
Three servers running Velrix OS, each with velrix-netd joined to the others by Geneve over the physical network. The module mesh runs on that overlay: Edge on server 1 calls Billing, whose copy on server 2 has stopped, so the calls go to the copy on server 3.Server 1Velrix OSEdgeIdentityvelrix-netdsecurity groups, DNSGeneveServer 2Velrix OSBillingstoppedDatabasesvelrix-netdsecurity groups, DNSGeneveServer 3Velrix OSBillingnow calledSitesvelrix-netdsecurity groups, DNSGeneve overlay between servers
Edge's calls to Billing go to the copy on server 3

Security reports

Report a vulnerability in any Hypefox brand or in our network to contact@hypefox.net.

The same address is published in /.well-known/security.txt.