BSD Cafe Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== BSD Cafe - Technical Details ======

Currently, the infrastructure of BSD Cafe relies entirely on FreeBSD, with both IPv4 and IPv6 connectivity.

The base setup is divided into jails:

  * A dedicated jail hosts Nginx, serving as a reverse proxy. It manages certificates and directs traffic. This is also serving the [[https://element.bsd.cafe|https://element.bsd.cafe]] Matrix web client
  * Another jail contains a small <del>OpenSMTPD</del>  Postfix server, handling email dispatch internally to avoid external service reliance.

The [[https://mastodon.bsd.cafe|https://mastodon.bsd.cafe]] instance is structured as follows:

  * A jail holds KeyDB, essential for communication among Mastodon services - the nervous system of BSD Cafe.
  * Another jail runs KeyDB for the Mastodon cache
  * Another jail runs PostgreSQL, serving as the database - the memory of BSD Cafe.
  * There's a separate jail designated for media storage, acting as the 'multimedia memory' of BSD Cafe. This jail resides on an external server with rotating disks <del>behind Cloudflare</del>. There are [[:bsdcafemedia-reverse-proxies|reverse proxies]] located in various parts of the world that receive and cache requests, serving them from the nearest server. The goal is to use georeplicated caching of multimedia data to reduce bandwidth consumption. The selection of reverse proxies is handled at the DNS level through a PowerDNS LUA script. More details have been documented here: [[https://it-notes.dragas.net/2024/08/26/building-a-self-hosted-cdn-for-bsd-cafe-media/|Building a Self-Hosted CDN for BSD Cafe Media]]
  * Two jails host the Mastodon application itself, including sidekiq, puma, and streaming components. This is where all processing and connection management occur. They're running in different hosts and are both providing some sidekiq queues and one of the two is set as a backup puma and streaming server when the first one (more powerful) is down. This is useful when updating, to avoid downtime.

[[https://wiki.bsd.cafe|https://wiki.bsd.cafe]] is confined within a single jail and runs the nginx, php and (of course) the [[https://www.dokuwiki.org/|DokuWiki]] CMS.

[[https://miniflux.bsd.cafe|https://miniflux.bsd.cafe]] is structured similarly, contained within a single jail, housing both the Miniflux software and PostgreSQL. In this case, we utilize a local installation.

[[https://freshrss.bsd.cafe|https://freshrss.bsd.cafe]] is a single jail service, housing both the [[https://freshrss.org/|FreshRSS]] stack (Apache and PHP) and PostgreSQL.

[[https://matrix.bsd.cafe|https://matrix.bsd.cafe]] is structured similarly, contained within a single jail, housing both the Synapse software, PostgreSQL and the Whatsapp bridge. In this case, we utilize a local installation.

[[https://blendit.bsd.cafe|https://blendit.bsd.cafe]] is composed of two FreeBSD jails: one for PostgreSQL, and the other contains the rest (the frontend in Node and the backend in Rust).

[[https://press.bsd.cafe|https://press.bsd.cafe]] is a FreeBSD jail running all the stack for Wallabag: nginx, php, postgresql, valkey.

[[https://brew.bsd.cafe|https://brew.bsd.cafe]] is a FreeBSD jail running PostgreSQL, KeyDB and Forgejo.

[[https://snac.bsd.cafe|https://snac.bsd.cafe]] is a FreeBSD jail running [[https://codeberg.org/grunfink/snac2|Snac2]]. Only a few strict Snac2 dependencies have been installed.

[[https://status.bsd.cafe|https://status.bsd.cafe]] is a FreeBSD jail running [[https://uptime.kuma.pet/|Uptime Kuma]]. This will monitor the other services' reachability and lives in an external VPS.

All communication takes place through a Wireguard routed setup. More details here: [[https://it-notes.dragas.net/2024/08/01/evolving-bsd-cafe-from-bridging-to-routing/|https://it-notes.dragas.net/2024/08/01/evolving-bsd-cafe-from-bridging-to-routing/]]

Some network statistics are available at [[https://netstats.bsd.cafe|https://netstats.bsd.cafe]]

Backups are systematically generated via ZFS snapshots and externally replicated across two distinct machines located in separate data centers, different from the production VPS data center.