Pharos Framework

What Pharos Framework does today

Hosts multiple apps in one runtimeMount apps under base paths such as /ucal and /dev_docs from one shared Pharos deployment.

Supports static and dynamic app profilesServe fully materialized static app bundles or dynamic apps backed by the native runtime and relational storage.

Keeps app authoring declarativeApp manifests, templates, fixtures, assets, and config describe app behavior while the shared runtime handles the mechanics.

Packages deployable app artifactsBuild apps into checked artifact directories with copied config, fixtures, docs, compiled host artifacts, and runtime metadata.

Owns operational behavior centrallyLogging, CSRF, health, readiness, backup, restore, validation, and deploy-facing runtime behavior live in shared framework code.

Uses a native C runtimeDynamic request handling, transport seams, database support, and packaged serving live in the native runtime rather than app-owned glue code.

How app authoring works

Pharos is designed so app teams spend most of their time authoring app-owned declarative files instead of rebuilding the same runtime plumbing over and over.

In a typical app, you define:

pharos.app.json for app identity, runtime profile, asset locations, and fixture locations
templates/ for app-owned HTML and page fragments
fixtures/ and data/ for route, surface, workflow, and app data declarations
static/ and media/ for shipped assets
app.conf for deploy-local overrides such as base path, state paths, and database settings

The runtime then turns those declarations into a running app with shared request parsing, rendering, packaging, and deployment behavior.

Why teams would choose it

Fewer moving parts per appThe framework centralizes transport, logging, health, packaging, and request-path mechanics so app bundles stay focused on product concerns.

Consistent deployment shapeApps build into a predictable artifact layout and deploy behind one shared runtime contract.

Good fit for internal and operational toolsPharos is especially suited to server-rendered apps, admin-style apps, workflow-heavy apps, and product surfaces that benefit from shared runtime discipline.

Easy to host togetherMultiple apps can coexist under one runtime instead of requiring one isolated server stack per app.

Business logic Pharos scaffolds today

Pharos already scaffolds a meaningful class of business logic when the app fits the current framework-owned generated surface model.

route matching from checked route fixtures
generated admin CRUD behavior
generated API CRUD behavior
shared validation, coercion, and relation checks
capability and policy gating
tenant and context scoping
collection filtering, sorting, projection, and pagination
shared audit-event emission for generated writes

This means Pharos already scaffolds real admin-style and API-style domain behavior from declarative manifests, fixtures, and templates. The strongest current path is generated CRUD, not arbitrary custom workflow logic.

Current app model

Pharos currently supports two main hosting profiles:

static-pages — packaged static app artifacts with app-local content
dynamic-app — runtime-served apps with declarative inputs, native request handling, and relational persistence support

SQLite and PostgreSQL are the supported relational backends. Runtime scratch JSON files may exist as operational surfaces, but they are not the primary source of truth when a relational backend is active.

Start with: