Corevia is evolving beyond a traditional PHP framework.
It is being designed as a multi-runtime application framework where PHP can remain the core application layer while Python, JavaScript, React, Dart and Flutter can participate through defined contracts, SDKs and services.
The goal is not to replace every technology with PHP.
The goal is to let different technologies do what they are best at — without turning the application into an integration mess.
What Corevia already focuses on
• Modular Actions, Flows and Events
• Durable workflows with retries, pause/resume and compensation
• Runtime idempotency and failure isolation
• Realtime communication through WebSockets
• PHP ↔ Python interoperability
• Cross-runtime application architecture
• HTTP routing and API development
• Database adapters
• CLI tooling and runtime inspection
• Lightweight PHP 8.2+ core
• Architecture designed for custom web applications, APIs, workers and business systems
Multi-platform direction
Corevia is also being expanded to make frontend and application clients easier to integrate.
The direction includes support and SDK patterns for:
• React — web applications and dashboards
• JavaScript / TypeScript — browser and application clients
• Dart — cross-platform application integrations
• Flutter — mobile, desktop and cross-platform clients
• Python — workers, automation, AI services and specialized processing
Instead of tightly coupling these runtimes, Corevia is moving toward explicit contracts that define how applications communicate with the framework.
AI is also becoming an important part of Corevia
AI support in Corevia is not intended to mean simply adding a chatbot endpoint.
The framework architecture is being designed so AI can participate as another application capability.
That opens the door for things such as:
• Local and hosted LLM integrations
• Python-based AI workers
• AI-powered automation flows
• Background inference jobs
• AI agents operating through controlled application actions
• Retrieval and knowledge systems
• Structured tool execution
• AI-assisted CRM and business workflows
• Chatbots and auto-repliers
• Classification, extraction and summarization services
• Local/private AI deployments
• Multi-model provider adapters
The important part is control.
AI services should interact with the application through defined actions, permissions and contracts rather than receiving unrestricted access to the system.
Corevia V3 — Under Development
V3 has not been publicly released yet.
A significant portion of the roadmap has already been implemented internally, while development is continuing on the remaining architectural pieces.
Current V3 work includes stronger framework/application separation, safer upgrades, starter kits, application foundations, background processing, improved SDKs, AI-oriented capabilities and better developer tooling.
Six major architectural areas remain under active development:
1. Deterministic Module Composition
Making module registration, dependency resolution and boot order predictable and reproducible across environments.
2. Runtime Profiles / Capability Presets
Applications should be able to load only what they need.
For example:
Web
API
CLI
Worker
Realtime
AI
Hybrid
instead of booting every framework capability for every process.
3. Explicit Request & Worker Lifecycle
Clear lifecycle boundaries for:
• HTTP requests
• CLI commands
• background workers
• realtime processes
• long-running services
• AI workers
This becomes especially important when PHP and Python services operate together.
4. Machine-Enforced Architecture Boundaries
Architectural rules should not exist only in documentation.
Corevia should be able to detect and prevent invalid dependencies, module violations and incorrect application structure automatically.
5. Reproducible Build & Configuration Fingerprints
A Corevia application should be able to identify exactly which framework configuration, modules and runtime capabilities produced a particular deployment.
This should make development, staging and production environments easier to compare and reproduce.
6. Cross-Runtime Contract Manifest
One of the most important V3 pieces.
A formal contract layer for:
PHP
Python
JavaScript
React
Dart
Flutter
and future runtimes
The manifest will define things such as:
• available actions
• payload contracts
• capabilities
• runtime requirements
• validation rules
• version compatibility
• remote-service discovery
The objective is to make cross-runtime development predictable rather than relying on loosely documented API agreements.
Corevia V3 is not about adding features just to make the framework larger.
It is about making the framework:
More deterministic.
More modular.
More portable.
More AI-ready.
More cross-platform.
And safer to scale across multiple runtimes.
The underlying philosophy remains simple:
Keep simple applications simple — while giving complex systems room to grow.
Top comments (0)