README

Kip is a plain-PHP, batteries-included framework for server-rendered apps: you write PHP classes and templates, and Kip handles routing, sessions, auth, database migrations, caching, uploads, email, the audit log, and a schema-driven admin panel. It has zero runtime dependencies (Composer is used only for autoloading), zero JavaScript, and one dependency you already have: PHP 8.3+.

Kip's deployment contract is part of the pitch: it runs unchanged on ordinary shared hosting (cPanel-style PHP 8.3 accounts) and on the cheapest VPS tier, with no build step, no Node, and no config wrangling. One server, one SQLite file, PHP-FPM or Apache; a single self-contained binary via kip build when you want the whole app as one executable.

It exists because the PHP world splits into two corners that leave a real gap between them. Full-stack frameworks ship everything (queues, broadcast channels, build pipelines, an SPA-era front end), and your app carries the dependency graph and the conventions for its whole life. Micro-frameworks ship a router and little else, so the first real application needs auth, migrations, CSRF, throttling, password reset, backups, and an admin panel, each written from scratch one more time. Kip takes the middle: the batteries are decided, included, and tested, and the ceiling is deliberately low. One server, one SQLite database, HTML over the wire. If that is the kind of app you are building, whether it is your first or your fiftieth, Kip should feel like a head start.

Zero JavaScript means the framework: no build step, no bundler, no npm, and every framework feature works with scripting disabled. Your app is free to add plain JavaScript where it earns its keep; the default Content-Security- Policy permits it, and Kip will never require a JS framework or ship one.

Kip grew out of a 2011 framework called MVC-Lite, written by Danilo Stern-Sapad; this is its modern successor, rebuilt around everything that made small-framework apps painful in the fifteen years between.

A Simple Example

A controller is a class; the URL is the class name. app/src/Controllers/PostsController.php:

<?php

namespace App\Controllers;

use Kip\Request;
use Kip\Session;
use Kip\View;

final class PostsController
{
    public function __construct(private View $view, private Session $session, private Request $request) {}

    public function index(): string
    {
        return $this->view->render('posts/index', ['title' => 'Posts']);
    }
}

No route registration, no annotations, no configuration: /posts now renders app/views/posts/index.php. Start from the included skeleton and the dev server is three commands away:

git clone https://github.com/Hyperion360/kip.git && cd kip/skeleton
composer install
php bin/kip serve

New to PHP, or to frameworks? The tutorial takes you from an empty folder to a working blog in about an hour, and it assumes no framework experience.

What Is in the Box

The included features are the batteries, and every one is on by default and removable by deleting its config.php key. Absence means off.

Convention routing: /controller/action/args from class names; a machine-readable routing table comes free.
Auth: login/logout with session-ID regeneration, password epochs (changing a password revokes every prior session), login throttling, split reset-token rate buckets, timing-equalized responses, and password reset over email.
CSRF: enforced on every non-GET request; query-string tokens rejected.
Database and migrations: SQLite in WAL mode by default, code-first migrations with atomic batch rollback, PHP or .sql migration files.
Page cache: full-page caching with table-level tag invalidation, ETag/304 conditional GETs. Cache poisoning and personalization are designed out: sessions, cookies, and writes never touch the cache.
Audit log: every request timed and logged to a separate database, with secret redaction.
Admin panel: schema-driven CRUD over your tables with masked secrets, two-step deletes, and a strict allowlist. Zero JavaScript.
Uploads: extension denylist and allowlist, magic-byte content checks, authoritative on-disk size, random names.
Email: SMTP (with STARTTLS peer verification and strict timeouts) or mail(), CRLF-injection-safe headers, a mail driver that logs to disk for development.
Backups: one command. Online-safe VACUUM INTO snapshots with retention pruning, zip or plain copies.
Testing: an in-process test client (TestClient) with CSRF and session handling built in; the framework's own suite runs to ~97% line coverage with no database server and no network.

How Kip Is Different

Zero runtime dependencies, as a contract. composer.json requires exactly php >= 8.3 and ext-pdo: zero packages, not merely few. The dependency list never grows; optional features may use bundled PHP extensions, never a package.
Zero JavaScript, as a contract. Every feature, including the admin panel and two-step deletes, works with scripting disabled. There is no build step, no bundler, no npm.
The batteries are decided. Where micro-frameworks leave auth, caching, and migrations as an exercise, and full-stack frameworks make each one a configuration surface, Kip ships one opinionated, tested version of each. The design decisions page gives the reasoning behind every one of those calls, in writing, including the short list of things Kip will never add.
One server, one database. SQLite in WAL mode with a file per concern (data, logs, cache), vertically scaled. That ceiling is a documented design decision, not an oversight: if your app someday genuinely needs horizontal scale-out, a different framework is the right call, and the design decisions page explains the trade.
Small enough to read. ~31 source files, every class final, no inheritance hierarchies to trace. A PHP developer who has never seen Kip should understand a controller in one pass.

Documentation

Tutorial: build a blog with Kip in about an hour, starting from skeleton/ and ending at the complete examples/blog/ app. Start here.
User guide: sixteen chapters: one per battery, plus the performance contract and a workflow for building with AI agents.
Architecture: how the pieces fit together; request lifecycle, cache invalidation, security lanes.
Versioning: the versioning and stability contract.
Design decisions: the reasoning behind Kip's scope, boundary by boundary, including what it will never include and why.

This repository holds three units: the framework core (src/ + tests/, the kip/framework package), skeleton/ (the minimal app template, auth pre-wired), and examples/blog/ (the finished tutorial app).

Framework Development

composer install
vendor/bin/phpunit   # needs `php` 8.3+ on your PATH

The suite is self-contained under tests/: fixture controllers and views in tests/Fixtures/, no database server, no network, no dependence on skeleton/ or examples/blog/.

Every change lands with a changelog fragment, never a hand-edited CHANGELOG.md: one changelog.d/<slug>.md file per change holding one type-prefixed line (Added:, Changed:, Fixed:, Security:, Deprecated:, Removed:). Nobody edits CHANGELOG.md by hand. A release is PATH="/opt/homebrew/bin:$PATH" php bin/release <x.y.z>, the maintainer's review of the printed notes, and a separate, explicit push of the tag; the full policy (who owns each release decision, fix branches) is in CONTRIBUTING.

Contributing

Bug reports, documentation fixes, and pull requests are welcome, and questions are always fair game. Kip's scope is deliberately narrow, and the design decisions page argues for every boundary instead of just asserting it. Disagree with one? Open an issue and make the case: the no list is a stability promise, not a closed door, and a well-argued proposal will always get a serious reading. What is settled is only that scope changes go through that argument first.

License

MIT. See LICENSE. Kip is written and maintained by Danilo Stern-Sapad on behalf of Hyperion360 Inc.

kip / framework

Package info

Security

Statistics