Winter Kernel

📖 winterframe.net/docs · Install · Quick start · Key concepts

Every link here points at winterframe.net and is language-neutral — the site serves the page in your language, RU or EN. Both are complete.

The kernel of the Winter framework: the package you install, and the only one you install directly. It turns a directory of classes into a running application — routing, request binding and validation, responses, dependency injection, managed processes and daemons, scheduling, localization, diagnostics and the console.

It is a library, not a skeleton. There is nothing to scaffold and no directory tree to create: you add it to a project, write one class saying what the application contains, and run it.

What is not in it

The database layer and the Redis client are separate packages, installed on demand. The kernel knows just enough about them to find your classes and hand them over when the package is there — an application that talks only to an external API should not carry an ORM, a connection pool and a migration engine it never loads.

Package	What it adds	Docs
flytachi/winter-ppa	Repositories, entities, query builder, migrations, DB pool	PPA
flytachi/winter-redis	Pooled Redis: prefixed stores, hashes, lists, streams	Redis

See Ecosystem for the full picture, including the libraries the kernel already brings with it (DI, logger, CDO, thread).

---

Requirements

PHP	8.4+
Required extensions	pcntl, posix, fileinfo
For the HTTP server	swoole — coroutines, connection pooling, static files
Optional	pdo (database) · bcmath, decimal (exact numbers) · simplexml (XML bodies)

Everything else comes from composer. Details: Installation.

---

Install

composer require flytachi/winter-kernel

Mini start — two files

bootstrap.php — loads the autoloader and declares what the application contains:

<?php

declare(strict_types=1);

use Flytachi\Winter\Kernel\App\Attribute\EnableWeb;
use Flytachi\Winter\Kernel\WinterApplication;

require __DIR__ . '/vendor/autoload.php';

#[EnableWeb]
final class Application extends WinterApplication
{
    public static function main(array $argv): never
    {
        parent::run($argv);
    }
}

call — the single entry point for everything, the server included (chmod +x call once):

#!/usr/bin/env php
<?php

chdir(__DIR__);
require './bootstrap.php';

Application::main($argv);

chdir() is not decoration: it ties .env, storage/ and resources/ to the project rather than to wherever the command was typed, which is what makes calls from cron, systemd and docker exec predictable.

That is a working project — no .env, no directories. The kernel creates what it needs when it needs it.

php call            # the command list
php call run        # bring the application up
php call run dev    # same, restarting when a .php file changes

Add a controller anywhere under the project; the scan finds it, no registration:

use Flytachi\Winter\Kernel\Http\Stereotype\Controller;
use Flytachi\Winter\Kernel\Route\Annotation\GetMapping;

final class PingController extends Controller
{
    #[GetMapping('/ping')]
    public function ping(): array
    {
        return ['pong' => true];
    }
}

curl http://localhost:8000/ping     # {"pong":true}

Walk-through with a path variable, a query parameter and the JSON it returns: Quick start.

---

What the application contains — #[Enable*]

The attributes on the application class are the manifest. Each adds a component; declare none and boot fails rather than starting an application that does nothing.

Attribute	Effect	Docs
#[EnableWeb]	the Swoole HTTP server	Routing
#[EnableScheduler]	runs #[Scheduled] methods on their triggers	Scheduler
#[EnableProcess(Foo::class)]	a managed worker beside the server	Processes
#[EnableDaemon(Bar::class)]	a supervised fleet of workers	Daemons
#[EnableAsync]	proxies #[Async] methods so they run off the request	Async
#[EnableActuator]	/actuator — health, pools, metrics, mappings	Actuator
#[Import('vendor/pkg', '/prefix')]	mounts a package under a URL prefix	Packages

Everything else is an ordinary class the scan finds — there are no configuration hooks to override:

#[Configuration] / #[Bean]   // DI factories            → dependency-injection
WebConfigurer                // host, port, CORS, static → web-configuration
LoggingConfigurer            // extra log channels       → logging

Full list and the rules: Components.

---

Documentation map

The whole reference lives at winterframe.net. The tree below mirrors the site's own navigation.

1. Introduction — what this is, and whether it fits you

1. What is Winter
2. Philosophy
3. Key concepts
4. Ecosystem

2. Getting started — from an empty directory to a served request

1. Installation
2. Project structure
3. Configuration
4. Quick start
5. Dependency injection
6. Basic connections

3. Web basics — everything between the request and the response

1. Routing
2. Web-layer configuration
3. Controllers
4. Middleware
5. Requests and parameter binding
6. Validation
7. Responses
8. Cookies
9. Views
10. Error handling

4. Background components — work that outlives a request

1. Components
2. Processes
3. Daemons
4. Scheduler

5. Database (PPA) — needs flytachi/winter-ppa

1. PHP Persistence API
2. Connection
3. Entities
4. Repositories
5. Pagination
6. Migrations
7. Connection pool

6. Redis — needs flytachi/winter-redis

1. Redis
2. Configuration
3. Stores
4. Hashes
5. Lists
6. Streams
7. Connection pool

7. CLI — the call command and everything under it

1. Overview
2. make — generate a component
3. cfg — .env, keys, Docker, completion
4. run — serve the application
5. db — ping, migrate, SQL preview, pools
6. mapping — the route table
7. storage — service directories
8. script — your own commands
9. di — scanner cache and #[Async] proxies
10. process — start, stop, status
11. daemon — fleets of workers
12. schedule — the scheduler

8. Advanced — the parts you reach for later

1. Logging
2. Localization
3. Asynchronous calls
4. Actuator / Health
5. File storage
6. Packages
7. Runtimes (FPM and Swoole)

---

License

MIT — see LICENSE.