Introducing Corevia 2.0 — A Modular PHP Runtime and Full-Stack Framework

I've been working on Corevia, an open-source PHP framework and application runtime designed around modular applications, durable workflows, isolated failures, realtime communication, and cross-language interoperability.

Today, I'm making Corevia 2.0 publicly available.

GitHub:

https://github.com/corevia-framework/corevia

Corevia requires PHP 8.2+, and its PHP core has no mandatory third-party runtime dependencies.

You don't need Node.js, Python, Redis, a message broker, Docker, or even a database just to start an application.

git clone https://github.com/corevia-framework/corevia.git myapp
cd myapp

composer install
php corevia serve

Then open:

http://127.0.0.1:8081

That's enough to run the database-free starter application.

Why build another PHP framework?

That's probably the first reasonable question.

Corevia isn't intended to replace every existing PHP framework or compete by providing another variation of MVC.

The project started around a different question:

What if workflows, failure handling, idempotency, realtime communication, modular boundaries, and external workers were first-class runtime concepts instead of application-specific plumbing?

A lot of applications eventually need things like:

multi-step business processes

retries

partial failure handling

idempotent operations

background or remote execution

realtime updates

service/module isolation

external workers

execution tracing

These often get implemented separately at the application level.

Corevia attempts to provide a consistent runtime model for them.

Actions, Modules and Flows

The main runtime concepts are intentionally explicit.

An Action performs a unit of work.

A Module owns and exposes actions and flows.

A Flow coordinates multiple actions.

A minimal example looks like this:

use Corevia\Core{
Corevia,
Action,
ExecutionContext,
State,
Flow,
Module,
ModuleContext
};

final class Increment implements Action
{
public function handle(
State $state,
ExecutionContext $context
): State {
$state->data['count'] =
($state->data['count'] ?? 0) + 1;

    return $state;
}

}

final class CounterModule implements Module
{
public function name(): string
{
return 'counter';
}

public function dependencies(): array
{
    return [];
}

public function register(ModuleContext $context): void
{
    $context->actions([
        'counter.increment' => Increment::class,
    ]);

    $context->flows([
        Flow::define('count')
            ->step('counter.increment')
            ->critical(),
    ]);
}

}

$app = Corevia::create(basePath: DIR);

$app->modules([
CounterModule::class,
]);

$app->boot();

$result = $app->run(
'count',
['count' => 0],
key: 'operation-1'
);

Modules explicitly declare their dependencies.

A flow can only execute actions owned by its module or by dependencies it has explicitly declared.

This makes module boundaries part of the runtime rather than just a directory convention.

Durable workflows

Corevia flows can express behavior such as:

Flow::define('checkout')

->step('cart.validate')
->critical()

->step('payment.charge')
->critical()
->retry(
    2,
    delayMs: 100,
    exponential: true
)

->step('email.send')
->nonCritical()
->retry(5)

->step('audit.write')
->when(
    fn (State $state) =>
        $state->data['audit'] ?? false
);

A failed critical step stops the flow.

A failed non-critical step can allow later steps to continue.

Flows can retain information including:

execution state

step status

timing

retry attempts

errors

trace IDs

request IDs

timestamps

Corevia 2.0 also adds support for concepts such as:

durable pause and resume

human or event checkpoints

retry policies

compensation

execution timelines

output contracts

This is intended for processes where simply throwing an exception and restarting the whole request isn't enough.

Idempotency is part of the runtime

Flows can be executed with an idempotency key:

$result = $app->run(
'checkout',
$input,
key: 'checkout-123'
);

Submitting the same flow and input with the same key can return the existing run instead of duplicating the operation.

If the input changes while reusing the same key, Corevia can report an idempotency conflict.

This becomes particularly useful around operations such as:

payments

order creation

external APIs

webhooks

retries

distributed requests

Actions can also derive operation-specific keys for protecting side effects.

Failure isolation

One of the design goals of Corevia is that one broken module should not necessarily take down unrelated healthy modules.

Module registration is explicit and isolated.

The runtime can detect problems such as:

missing dependencies

disabled dependencies

dependency cycles

duplicate identifiers

duplicate public names

while allowing unrelated modules to continue booting where possible.

Realtime communication

Corevia includes its own realtime layer with WebSocket support.

You can start it separately:

php corevia realtime:start

and run the HTTP application with:

php corevia serve

The runtime supports concepts including:

public channels

private channels

presence channels

authorization

heartbeat handling

reconnection metadata

rooms

authenticated local IPC

Realtime execution stays separate from PHP-FPM or the normal HTTP process.

PHP communicating with other runtimes

Corevia also includes CVP, its protocol layer for communication between runtimes.

For example, a PHP application can invoke an action implemented in a Python worker.

A worker can expose an action like:

from corevia import Worker

worker = Worker(
'http://127.0.0.1:8090',
token='development-shared-secret'
)

@worker.action('ai.analyze')
def analyze(payload):
return {
'characters': len(payload['text'])
}

worker.run()

The PHP runtime can then invoke the remote action through Corevia rather than requiring the Python implementation to become part of the PHP process.

Corevia currently includes protocol support and SDK work across:

PHP

JavaScript

Python

Dart

There is also thin integration for React and React Native.

Database support without making a database mandatory

A database is not required to boot the Corevia starter.

When persistence is needed, Corevia 2.0 includes support for named PDO connections including:

MySQL / MariaDB

PostgreSQL

SQLite

There are also optional connectors for:

MongoDB

local JSON document storage

The runtime and persistence layers remain separated so the core doesn't directly depend on PDO or a specific database implementation.

Corevia can also behave like a normal web framework

V2 includes a web application layer with familiar concepts:

app/
routes/web.php
resources/views/
public/assets/
config/settings/

The web layer includes functionality such as:

routing

controllers

middleware

named routes

route groups

constraints

redirects

resource routes

PHP views

signed CSRF forms

So Corevia isn't limited to workflow execution or backend services.

It can also host the application using those runtime capabilities.

CLI tooling

Corevia includes a CLI for development and runtime inspection.

Some available commands include:

php corevia serve

php corevia doctor

php corevia modules

php corevia routes

php corevia flow:list

php corevia flow:run checkout \
--input=examples/checkout.json \
--key=demo-checkout

php corevia flow:show

php corevia flow:retry

php corevia realtime:start

php corevia realtime:stop

php corevia make:module Example

php corevia make:action Example

php corevia make:flow Example

The goal is to make runtime behavior inspectable rather than hiding everything behind application code.

Architecture

At a high level:

HTTP / CLI / event / scheduled invocation
|
v
Module Registry
|
v
Flow Engine
|
v
Action Runner
|
v
Explicit Result

    Flow Engine
         |
         v
      RunStore

    Action Runner
         |
         v
    EventBus Contract
         |
         v
 Realtime Broadcaster
         |
         v
   WebSocket Clients

Remote runtimes can connect through CVP:

PHP Runtime
|
| CVP
v
Python Worker

JavaScript / React Native
|
| HTTP + WebSocket
v
Corevia

No mandatory infrastructure just to get started

One thing I wanted to keep deliberate was the initial dependency footprint.

The basic PHP runtime does not require:

Database -> No
Redis -> No
Node.js -> No
Python -> No
Broker -> No
Docker -> No

Start with PHP.

Add infrastructure when the application actually requires it.

Testing

The project includes automated testing across:

PHP 8.2
PHP 8.3
PHP 8.4

It also includes integration coverage involving:

HTTP

WebSockets

PHP/Python workers

SDK contracts

idempotency

failure handling

reconnect behavior

MySQL

PostgreSQL

MongoDB

database-free execution

Current status

Corevia 2.0.0 is the current stable V2 release.

V1 remains available through the v1.0.0 tag.

There are still intentional boundaries.

For example:

some in-process deadlines are cooperative

offline realtime events aren't replayed automatically

external pub/sub requires an adapter

some single-node facilities require external infrastructure when scaling horizontally

I prefer documenting those limits rather than pretending the framework magically solves distributed systems.

Also, the packages have not yet been published to Packagist, npm, PyPI or Dart package registries.

For now, Corevia is installed directly from the repository/source.

Open source

Corevia is released under the MIT License.

The repository includes documentation covering the kernel, flows, web layer, databases, protocol, deployment, migration, and contribution process.

If you work with PHP and any of these areas interest you:

workflow engines

modular architecture

resilient applications

realtime systems

distributed application runtimes

PHP/Python interoperability

framework internals

I'd genuinely like technical feedback.

Especially criticism.

If something in the architecture looks unnecessary, unsafe, overly complicated, or could be expressed in a better PHP-native way, I'd like to hear it.

GitHub:

https://github.com/corevia-framework/corevia

Issues, discussions, tests, documentation improvements, and contributions are welcome.

Corevia 2.0

Build modular applications. Keep failures explicit. Connect runtimes when you need them.