Guide

The complete guide to building with Phlo: from installation and your first route to realtime applications and the philosophy behind the language.

1IntroductionPhlo is an integrated platform with its own full-stack language. You write .phlo source files; Phlo transpiles them to PHP, CSS and JavaScript you can open and read, with every runtime error pointing back at the .phlo line you wrote. The same language carries four layers: the language itself, the application platform (backend resources plus the phlo.js SPA engine), the server platform (FrankenPHP, the Phlo Daemon, Phlo Realtime, Phlo WhatsApp) and the operations platform (the Phlo Dashboard). This guide covers all of them. The production release runs on a shared runtime, usually in /opt/phlo/, while each app keeps its own source, data, generated PHP and webroot. 2Configurationdata/app.json describes the build: which resources are loaded, where release output goes, and which resources belong only in release or only in dev. 3Runtime configdata/app.json describes the build, what gets transpiled. This chapter covers the runtime, what happens on each request. That config lives in www/app.php (and, for stage/release, release/www/app.php) as arguments to phloapp(...). 4Syntax & StructurePhlo transpiles .phlo source files to plain PHP classes and generated assets. The syntax is PHP-like, but without semicolons at the end of statements. 5RoutingRouting in Phlo maps a space-separated path + HTTP method to a target (usually a method). 6ViewsViews live directly in .phlo files. A view transpiles to a PHP method that returns HTML. You render a view with view(...). 7CSSPhlo uses a compact, semicolon-free CSS syntax inside <style> blocks. 8ORMPhlo ships with a powerful built-in ORM that lets you define database tables as classes. 9Instance ManagementPhlo uses its own instance manager to initialize and reuse objects efficiently and predictably. This system determines when controller code runs, how instances are stored, and how circular references are prevented. 10Tooling & CLIPhlo apps have a CLI layer for build, lint, release and reflection. Always use it through the app's dev entrypoint. 11TranslationsPhlo uses the lang resource for multilingual view text and translation. In views, you write static text preferably with the compact language shorthand. You write source text in your own language; the examples below use Dutch (nl) as the source language. 12AdvancedPhlo stays deliberately modular. You can keep an app small and activate only the resources it needs, or combine multiple source paths and resource groups. 13AppendicesThese appendices give compact examples that match the production release. 14WebSocketRealtime in Phlo runs through Phlo Realtime, the WebSocket server built into the Phlo Daemon(/guide/daemon). One Node process owns the socket connections across every vhost and runs each event on your PHP app through the daemon's own worker pool. Your app implements four hook functions and broadcasts from PHP with wsCast(). 15TasksPhlo has a built-in cross-app task runner. Something triggers tasks::run every minute, a system cron entry or the Phlo Daemon(/guide/daemon); the tasks resource matches declaratively against %app->tasks. No cron syntax in your app, no external scheduler. 16DaemonThe Phlo Daemon is an optional Node sidecar (phlo-daemon.js): a generic engine that dispatches any Phlo target to a pool of persistent workers. Core Phlo works without it; the daemon makes the heavy paths faster and powers WebSockets and scheduled tasks. 17SEOThe seo resource centralises the search and sharing metadata an app needs: sitemap.xml, robots.txt, hreflang alternates, the canonical link, and a <head> block of <meta> description plus Open Graph and Twitter cards. It derives everything from props you already set, so a uniform, complete-but-restrained set ships from one place. 18AIPhlo bundles a number of AI providers (OpenAI, Claude, Gemini, DeepSeek, Grok) behind a single facade. You pick a model, Phlo picks the right engine. Streaming to the DOM uses the same apply() mechanics as the rest of Phlo: no separate client-side library, no separate event bus. 19TracePhlo's trace mode is a runtime instrumentation layer that logs every call to a generated method, prop getter, static or native function with timing and arguments. Per request Phlo writes a JSON dump to data/trace/<id>.json. Meant for debugging and profiling, not for production. 20For AI AgentsPhlo is built to be driven by AI agents, not just read by them. Every app exposes three CLI layers that let an agent work without prior knowledge of the codebase: reflect:: to understand it, phloeval to execute against it, and build:: to transpile and verify. All three require build: true and must never run against production. 21PhilosophyThis chapter explains why Phlo is built the way it is: the deliberate trade-offs behind the parser, the transpiler, the runtime and the tooling. The short version: Phlo is an integrated platform with its own full-stack language, and its power is in the vertical integration of all layers, one language and one mental model from code to fleet. 22PerformanceA Phlo app that follows the conventions in this guide starts from a strong Lighthouse position, because the architecture already does most of what the audits measure: server-rendered HTML, one small deferred script, one stylesheet, no framework payload and no third-party requests. This chapter maps correct Phlo use to the web's performance best practices, and covers the part that remains yours: images, markup and measurement. 23Deployment & CI/CDA Phlo app is static once it is built. build::release transpiles your .phlo sources into plain PHP, CSS and JS under a release/ directory (see the Tooling chapter); production serves that output with no transpiler and no build step in the request path. Deployment is the act of getting a tested release/ onto the server and switching to it safely. 24PWA & native appsA Phlo app is already a website. The same build ships as an installable Progressive Web App with 25IntegrationsMost apps eventually talk to something outside themselves: a chat service, a calendar, an accounting back-end, a card terminal, a payment processor. Phlo ships two families for this, both in the runtime, so there is no SDK to bolt on and no separate client to wire up. Connectors are thin, uniform wrappers around JSON REST APIs; the payment resources wrap Stripe and SumUp.

We use essential cookies to make this site work. With your permission we also use analytics to improve the site.