← Back

Pharos Platform Vision

Pharos Framework is moving toward a clean split between declarative app authoring and a shared runtime that owns the difficult operational behavior.

Current platform story

Today the important Pharos story is practical rather than speculative:

• one framework can host multiple apps under one runtime
• apps can be packaged into predictable artifact directories
• the native runtime owns request-path behavior, transport handling, logging, CSRF, health, and deploy-facing mechanics
• app bundles can stay focused on manifests, templates, fixtures, assets, and app-local configuration
• dynamic apps can use SQLite or PostgreSQL while the runtime keeps persistence handling and operational conventions consistent

The goal is to reduce per-app plumbing and keep deployment behavior easier to reason about.

Declarative app boundary

Pharos is strongest when the app boundary stays declarative.

At the app layer, teams should primarily own:

• pharos.app.json
• route, surface, workflow, and related fixtures
• templates and fragments
• static and media assets
• seed and content data
• app-local deploy configuration

At the framework layer, Pharos should own:

• request parsing and routing behavior
• rendering semantics
• transport and listener behavior
• database/runtime coordination
• logging and error reporting
• CSRF and shared runtime protections
• packaging and deploy validation
• health, readiness, backup, and restore surfaces

That split keeps app bundles readable and portable while letting the framework absorb the operational complexity once.

Multi-app hosting direction

A core Pharos advantage is shared hosting for multiple apps.

That means the runtime should continue improving at:

• app discovery and base-path mounting
• packaging consistency across apps
• predictable per-app config overrides
• deployable artifact layouts
• safe shared runtime logging and health reporting
• operational tooling that works the same way across apps

The intent is that a team can host several related server-rendered products, admin tools, and support tools under one Pharos deployment without rebuilding the runtime story for each app.

Dynamic app direction

The current implemented strength for dynamic apps is framework-owned generated CRUD behavior plus shared runtime handling.

That means the strongest present business-logic story is:

• fixture-driven generated surfaces
• shared validation and authorization
• shared request-path and runtime behavior
• app-owned templates and declarative metadata

This page intentionally describes the platform from the perspective of current usable strengths rather than speculative framework claims.

Why this matters

Most teams do not need a novel theory. They need a framework that helps them ship and operate web apps with less duplication.

Pharos matters when it helps teams get all of these at once:

• server-first app delivery
• packaged build artifacts
• shared multi-app hosting
• database-backed dynamic apps
• centralized operational behavior
• app authoring that stays focused on product structure rather than runtime plumbing

Current status

Pharos is already a usable runtime, packaging surface, and multi-app host.

The main public documentation goal now is to describe that current reality clearly and help developers author better apps with the framework as it actually exists.