Your website.
Your server.
One file.

Get started in 3 steps

No terminal experience needed. Just download, double-click, and go.

How it works

The design decisions that make this possible, explained for programmers.

Why pure PHP replaces nginx

Nginx does three things: accept connections, serve static files, and proxy to PHP. We do all three in PHP. Static files are served with readfile() — same syscall pattern as nginx (stat() → open() → read() → write()). With HTTP/1.1 keep-alive, a page with 20 assets uses 1 TCP connection, not 20. Pre-compressed .gz / .br files are served directly (like nginx's gzip_static). For a personal or small community site, the throughput difference is unmeasurable.

Why fork-per-request beats php-fpm

PHP-fpm has two bad options: reload everything per request (~20ms overhead) or reuse processes with dirty state (memory leaks, secret leaks between requests). We do something better:

The parent preloads all PHP classes into memory before forking. Children inherit everything via the kernel's copy-on-write mechanism — the class definitions are already in memory, no autoloading needed. Each child handles exactly one request, then exits. No memory leaks. No secret leaks between requests. And it's faster than php-fpm's "reload everything" mode because the classes are already loaded.

Why shared-nothing wins

We deliberately chose not to reuse worker processes across requests. You could theoretically use PHP's Reflection API to reset every static variable, close every DB connection, flush every buffer — but you'd still miss edge cases. A process that served User A's authenticated session should never carry any residue when serving User B. The only way to guarantee that is exit(). The ~0.5ms fork cost is nothing compared to the security and reliability guarantees.

No database needed

The IndieWeb plugin stores everything as JSON files. Webmentions? A directory of JSON files keyed by URL hash. Feeds? Generated from HTML using the same hash/diff engine the framework uses for static asset cache-busting. For a personal site receiving a few dozen webmentions a day, a directory of JSON files is as fast as MySQL and infinitely simpler. SQLite is included for plugins that need relational queries, but the core server doesn't require it.

How the single binary works

We use static-php-cli to compile PHP as a fully static binary (musl libc, no dynamic dependencies) with exactly the extensions needed. Then phpmicro glues the PHP interpreter to a .phar archive containing the Q framework and your app:

micro.sfx + qbix-app.phar = qbix-server (one file, ~15MB)

Compare:
  Node.js SEA     ~50-90MB
  Deno compile    ~70-100MB
  Go binary       ~10-20MB
  qbix-server     ~10-15MB  ← competitive with Go

The binary runs on any machine of the same architecture. No PHP installation, no package manager, no container runtime. Copy the file, run it.

Securing files: three levels

File access has three distinct levels, and it's important not to confuse them:

X-Accel-Redirect is how you do real access control. The pattern: put protected files outside the web root (e.g. /app/files/), write a PHP script that checks permissions, then set the X-Accel-Redirect header pointing to the internal path. The server intercepts the header (never sends it to the client), resolves the path via configured mappings, and serves the file with readfile(). PHP never buffers the file body — it just says "this user is allowed, serve this file" and the server does the efficient I/O.

// In your access-check script:
$authorized = check_user_permissions($filename);
if ($authorized) {
    header("Content-Type: " . mime_content_type($filename));
    header("X-Accel-Redirect: /internal/uploads/" . $relativePath);
} else {
    throw new Users_Exception_NotAuthorized();
}

Configure the internal mapping in your app config:

{
  "Q": {
    "webserver": {
      "accel": {
        "mappings": {
          "/internal/uploads": "/var/app/files/uploads"
        }
      }
    }
  }
}

The server maps /internal/uploads/photo.jpg to /var/app/files/uploads/photo.jpg on disk, checks that it doesn't escape the mapped directory (path traversal protection), and serves it with ETag, compression, and proper headers. The /internal/ prefix is never directly accessible — only reachable via the X-Accel-Redirect header from PHP.

OS-level permissions

The server process should run as a non-root user (the systemd unit defaults to www-data). Set file permissions so the web directory is readable but not writable by the server, and the files/config directories are writable only where needed. The --systemd flag generates a unit file with ProtectSystem=strict and explicit ReadWritePaths.

HTTP/2 with amphp (transparent upgrade)

The built-in server speaks HTTP/1.1 with keep-alive — fast enough for most sites. For HTTP/2 (HPACK compression, stream multiplexing, flow control), just install amphp:

composer require amphp/http-server amphp/socket revolt/event-loop psr/log

That's it. Next time you start the server, it auto-detects amphp and prints → amphp detected — HTTP/2 + 4 prefork workers. Same command, same config, same routing. The architecture is the same either way — only the connection layer changes:

This is strictly better than both alternatives. Better than nginx + php-fpm: no IPC socket overhead, the parent serves cache hits and static files without touching a worker, and preloaded classes are inherited via fork() not reloaded per request. Better than pure async PHP: guaranteed clean state per request — no leaked sessions, no stale static variables, no memory growth. Each child handles one request and exits. The fork costs ~0.5ms. The guarantee is worth it.

PHP can do TLS (we support it for dev/personal sites), but for production the math is clear: cloud edge networks (Cloudflare, AWS CloudFront) and reverse proxies (Caddy, nginx) do TLS in optimized C/Go/Rust with hardware AES-NI and kernel sendfile(). They're 2-3× faster per byte and add HTTP/3 for free. The server speaks HTTP internally and lets the upstream handle encryption.

Three modes, one command

# HTTP/1.1, in-process (dev, zero deps)
php scripts/Q/webserver.php

# HTTP/1.1, prefork workers (production, zero deps)
php scripts/Q/webserver.php --workers=4

# HTTP/2, prefork workers (production, best of both)
composer require amphp/http-server amphp/socket revolt/event-loop psr/log
php scripts/Q/webserver.php --workers=4
→ amphp detected — HTTP/2 + 4 prefork workers

The full production stack

What it replaces

Each row eliminates a dependency that previously required money, expertise, or centralized infrastructure.

The bottom of the stack is the most radical: the transport layer itself becomes peer-to-peer. You don't need the internet to have a social network. You need proximity.