Meta description, canonical links, Open Graph, and Twitter Card tags ship by default, all overridable per page.
Built-in analytics tracking and a multi-user session login for /admin/* — both off until you turn them on in App/config.php.
A multi-user session login gates every /admin/* route, with email verification for new accounts. Off by default in App/config.php.
Gate a page to a user or group with one Lib\Access call in its sidecar, or preview an unfinished page as an admin-only draft.
An upload/browse/delete UI at /admin/media, and Lib\Comments for a moderated comment thread on any page.
Lib\Db wraps PDO for SQLite or MySQL, multiple named connections at once, migrating automatically on first use.
One content index backs full-text /search, /sitemap.xml, and blog tag browsing — reindexed lazily, no extra steps.
/blog/feed is built from the same hand-written post list App/pages/blog/index.php renders from — no database required.
Built-in analytics tracking, off by default, alongside a nav toggle that swaps every color via CSS custom properties.
+Lib\Csrf, Lib\SpamGuard's honeypot check, and cleaning input accessors — wired into the contact form and every admin form.
The root Dockerfile builds an Apache + PHP image on an Arch Linux base, with mod_rewrite, AllowOverride All, and pdo_sqlite/pdo_mysql already enabled — nothing else in Getting started's "Deploy on Apache" section needs configuring by hand. docker-compose.yml wires it up with three named volumes so a project's own cache, uploads, and database never live inside a path that gets wiped by the "Updating the framework" workflow.
The root Dockerfile builds an Apache + PHP image on an Arch Linux base, with mod_rewrite, AllowOverride All, and pdo_sqlite/pdo_mysql already enabled — nothing else in Getting started's "Deploy on Apache" section needs configuring by hand.
docker compose up --buildVisit http://localhost:8080/.
docker-compose.yml bind-mounts four host paths under ${VOL_PATH:-/data}/novaconium/ (override VOL_PATH in the environment to relocate all four at once) so a project's content, uploads, cache, and database live on the host — editable without a rebuild, and untouched by the "Updating the framework" workflow:
App → /var/www/html/App — the project itself (pages, lib, config, migrations). Edit it on the host; changes show up after docker compose restart web, no rebuild.cache → public/cache/ — the static HTML page cache (see Static caching). Disposable; clear it from inside the container with docker compose exec web php novaconium/bin/clear-cache.php.uploads → public/uploads/ — files uploaded through Media manager (/admin/media). Needs its own volume specifically because public/ is otherwise baked into the image with COPY at build time — without this, an upload would only survive until the next docker compose up --build. Kept separate from the data volume below deliberately, since a project might use MySQL or no database at all and shouldn't have upload storage coupled to the SQLite volume.data → data/ — holds data/novaconium.sqlite if Database-backed features (admin auth, content index) are enabled. Persists across docker compose down/up as long as you don't pass -v.uploads → public/uploads/ — files uploaded through Media manager (/admin/media).data → data/ — holds data/novaconium.sqlite if Database-backed features (admin auth, content index) are enabled.App/ itself is not a named volume — it's baked into the image with COPY at build time, so docker compose up --build alone produces a working site with no extra steps. A named volume seeded from COPY App/ would only populate once, on first container creation, and would silently go stale on every later rebuild. To edit content without rebuilding, uncomment the bind mount in docker-compose.yml:
A bind mount to a host directory shadows whatever the image's COPY put at that path — including with nothing at all, if the host directory doesn't exist yet or is empty. Docker doesn't seed a bind mount from image content the way it seeds a fresh named volume. Two consequences the plain image can't handle by itself, both worked around by docker-entrypoint.sh (the container's ENTRYPOINT, runs once per start before Apache):
volumes:
- - cache:/var/www/html/public/cache
- - uploads:/var/www/html/public/uploads
- - data:/var/www/html/data
- - ./App:/var/www/html/AppA bind mount at the same path as a COPY'd directory shadows the image layer at container start, so a host-side edit under App/pages/ shows up after docker compose restart web — no rebuild, no custom entrypoint logic.
App/ on first run. The Dockerfile stashes a pristine copy of the baked-in App/ at /opt/novaconium-app-default at build time. If the bind-mounted /var/www/html/App is empty when the container starts, the entrypoint copies that pristine copy in — so a first docker compose up against a fresh, empty ${VOL_PATH}/novaconium/App on the host produces a working site instead of a blank one. It only seeds when the directory is empty, so it never clobbers content you've already put there.chown -R http:http in the Dockerfile only applies to the image layer, not to whatever gets mounted over it. The entrypoint re-runs chown -R http:http on all four mounted paths on every container start, so Apache's worker user (http on Arch) can always write to them regardless of the host-side UID/GID — no manual chmod on the host required.Lib\Db supports MySQL alongside or instead of SQLite (see Database). docker-compose.yml has a commented-out db service and mysql-data volume — uncomment both, add a db_connections entry with driver: mysql and matching credentials in App/config.php, and the app container can reach it at hostname db.
Arch's repos are rolling-release, so the Dockerfile doesn't install apache/php/sqlite from the live mirror — it points pacman at a dated Arch Linux Archive snapshot via the ARCH_SNAPSHOT build arg (a YYYY/MM/DD path), so a rebuild next month installs the exact same versions as today instead of whatever's newest that day. To move to a newer snapshot deliberately (e.g. to pick up a PHP security release):
docker build --build-arg ARCH_SNAPSHOT=2026/08/01 --no-cache -t novaconium-beta .--no-cache is worth using any time you change the Dockerfile itself (not just App/ content) — Docker otherwise reuses a cached layer for an unchanged-looking RUN step, and docker-compose.yml here uses image: rather than build:, so docker compose up alone never rebuilds at all; you have to docker build (and re-tag, if needed) yourself first.
Arch's php-apache package is built against mpm_prefork, not httpd's default mpm_event — the Dockerfile swaps MPMs as part of the build. The Apache/PHP worker user on Arch is http, not Debian's www-data; the Dockerfile chowns the cache/uploads/data/App directories and novaconium/contact-log.txt to http:http at build time so a freshly created named volume (which inherits the image mountpoint's ownership) is writable immediately. If you swap a named volume for a bind mount pointing at a host directory with different ownership, that automatic chown doesn't apply — you may need to adjust permissions on the host side.
Arch's php-apache package is built against mpm_prefork, not httpd's default mpm_event — the Dockerfile swaps MPMs as part of the build. The Apache/PHP worker user on Arch is http, not Debian's www-data; both the build-time chown and docker-entrypoint.sh's startup chown (see above) target http:http for this reason.
This is a separate Dockerfile from the one-off Dart Sass build tool described in Styling — that one lives at Dockerfile.sass, a Debian-based image whose only job is running the sass CLI, not serving the app.