Download the PHP package modufolio/appkit without Composer

Appkit

A small, hand-wired PHP application kernel built on Symfony components, Doctrine ORM, Firebase JWT, and a strict-typed PSR-7 fork. Designed for security-conscious SaaS applications that want Symfony-grade components without Symfony's full kernel, bundle system, and compile step — until the application is big enough to want the last two, at which point it opts in.

In AppKit, your App class is the container. Symfony compiles a container class you never read; Laravel hides its container behind facades. Here the container is a class you write: services are typed methods on your App, lazily constructed and cached in properties you can see. There is nothing to compile, because you already wrote what a compiler would generate — and grep is the container debugger.

That is the right size for a small application, and it stays the kernel's model at every size. When the service graph outgrows hand-wiring — autowired trees, tags, compiler passes, modules that ship their own definitions — the application puts Symfony's DI container behind the kernel with one line. The kernel keeps first say on every id it declares; only an unknown id reaches Symfony. See The Symfony container behind the kernel.

Why it exists

• Slim is too thin. No Doctrine, no validation, no security primitives — the consumer wires everything.
• Symfony is too heavy. A compiled DI container, an event dispatcher, bundles, Flex recipes, and a bootstrap that has to be generated. Excellent for large apps; more than most SaaS workloads need.
• Laravel is opinionated and non-Symfony. Facades, ActiveRecord, and a separate ecosystem.
• Appkit sits in between. Symfony components plus Doctrine plus a thin abstract kernel, with a hand-compiled container so the file you read is the resolution path that runs — and the parts of Symfony's tooling that earn their keep, such as a make:entity generator ported from MakerBundle.

What AppKit deliberately doesn't include

Each of these is a stated choice with a documented alternative, not a gap:

• No application-level event bus. Extension happens through named seams: explicit interfaces (authenticators, user checkers, CSRF validators, package contracts answered in config/services.php), Doctrine's lifecycle events at the persistence layer, and plain method override — subclass your App and replace an accessor. Internal control flow stays a readable call stack.
• No queue abstraction. Background jobs run on RoadRunner's first-party jobs plugin — you are already running RoadRunner, and durability is a config swap, not a PHP layer. See Background jobs.
• No mailer, no i18n. Bring the PSR-compatible library your app needs and register it as an App method; the framework does not wrap what it cannot improve.
• No container-coupled console. The framework ships console commands, not a bin/console; the runner is application code. The RoadRunner reference (modufolio/appkit-roadrunner) boots its console without the app container, so a wiring bug can never take down the tool that fixes it; the skeleton's ConsoleRunner constructs each command by hand for the same reason. See Console.
• Security headers live at the edge (nginx/Caddy/CDN), where they also cover static assets — see What the framework does not handle.

What it solves

• Fast boot. No DI compile step, no cache invalidation, by default. Config files are loaded with require; OPcache handles the rest. The opt-in Symfony container is compiled per boot outside prod and dumped once in prod.
• Transparent control flow. No event dispatcher by design. Reading handleAuthentication() top-to-bottom shows exactly what runs.
• RoadRunner-aware. Every stateful service implements ResetInterface; the kernel rebuilds its ApplicationStateInterface state (NativeApplicationState) per request. The worker loop stays in your application rather than behind a runtime — see modufolio/appkit-roadrunner.
• Security hardening already wired. Symfony-style firewalls with method/host/IP restrictions; path- and attribute-based access control with a role hierarchy and trust-level attributes (IS_AUTHENTICATED_FULLY, IS_IMPERSONATOR, …); CSRF rotation on login; session-fixation defence; remember-me with optional persistent tokens (theft detection and rotation); HTTPS channel upgrades; brute-force protection; a token unserialize allowlist; password timing-parity; credential-length DoS caps; and boot-time firewall-config validation.
• Strict typing. PHP 8.2+, declare(strict_types=1) throughout. The PSR-7 implementation is modufolio/http, a separate package the framework depends on: a strict-typed fork of nyholm/psr7 under the Modufolio\Psr7\Http namespace.

Quick start

The skeleton lives in its own repository: modufolio/appkit-skeleton. composer start is the skeleton's Composer script — PHP's built-in server on port 8000 with router.php — not a framework command.

A minimal controller

AbstractController is a concrete base class despite its name — it is not declared abstract. The kernel fills its protected properties (entityManager, tokenStorage, urlGenerator, userProvider, validator, flashBag) right after construction. Extending it is optional: any class the router resolves works, and only subclasses get that treatment.

Documentation

Full guides under docs/:

• Getting started — install, configure, and run your first app
• Kernel — request lifecycle, service container, boot
• Routing — routes, parameters, access control
• Controllers — controllers and parameter attributes
• Inertia — returning Inertia pages, the renderer, the module
• Dependency injection — wiring services with config files
• Modules — self-contained feature packages: manifest, conventions, lifecycle
• Templates — layouts, snippets, sections, asset helpers
• Security — firewalls, access control, CSRF, roles, trust levels
• Authenticators — form login, JWT, OAuth 2.1, 2FA, remember-me, brute-force
• Database — Doctrine ORM, QueryBuilder, pagination, soft delete
• Forms — validation, ValidationResult, payload mapping
• Exception handling — turning exceptions into HTTP responses
• File uploads — validating and storing uploaded files
• Image processing — Darkroom, Dimensions, DiskManager
• Console — built-in commands (debug:firewall, security:validate, make:entity), writing your own
• Toolkit — array, file, string, and directory utilities
• Testing — PHPUnit, EntityFactory, static analysis
• Deployment — Nginx/Caddy, permissions, RoadRunner, databases
• Configuration — environment variables and config reference

Start with the introduction for the architecture overview and the design philosophy the rest of the documentation assumes.

Requirements

• PHP 8.2 or later
• Composer
• Extensions: curl, dom, fileinfo, intl, libxml, pdo, simplexml, sqlite3, zip
• Optional, for image processing: exif, gd and the claviska/simpleimage package — listed under suggest in composer.json, not required

See composer.json for the canonical dependency list.

License

MIT. See LICENSE.