What Blysis is

Blysis is a website platform whose core ships empty. It knows about accounts, roles, permissions, languages, navigation, rate limits, uploads and SEO, and it knows nothing about shops, forums, tickets or game servers. Those arrive as modules, installed from inside the running site.

That is not a preference about code organisation. It is the product: a site assembled from parts, where the parts you did not install leave no trace in the code, and where a module author only ever edits their own directory.

Three layers

Core is site-type-agnostic infrastructure. No module name, no module path and no theme name appears anywhere inside it, and three checks fail the build if that stops being true.

Modules are the feature layer. A module is a directory with a manifest, and the manifest declares everything the module contributes: pages, admin screens, API endpoints, a sidebar entry, permissions, cron jobs, hooks, database tables, translations. Nothing is discovered by scanning and nothing registers itself at runtime.

Themes are presentation. Colours, fonts, component overrides and slots, in one manifest, with light and dark in the same file.

Installing a module rebuilds the app

This is the one architectural fact that reaches operations, so it is worth knowing on the first page rather than the tenth.

A module ships React server components, and Next.js compiles those at build time. There is no runtime loader that could render them. So installing a module runs this, on a short debounce so installing thirty modules produces one build:

merge the schema -> apply table additions -> run migrations
-> regenerate the registry -> build -> record the fingerprint -> restart

Two consequences:

• Run the application under a supervisor. Docker Compose with restart: unless-stopped, systemd with Restart=always, or pm2. The Docker install does this for you.
• One application process per installation. Two processes sharing the modules volume would both build into the same directory, and the loser would serve a half-written build.

A build that fails is loud in the logs but does not stop the site: the previous build keeps being served, the admin panel stays reachable, and the module that broke it can be removed.

What it is not

It is not a CMS with a plugin system bolted on, and it is not a framework you write a site in. It is a running site that you add capabilities to, and the capabilities are versioned against a published contract rather than against whatever the core happened to export that week.