Skip to content
DevKit

Architecture

DevKit.app (Tauri, React) ─┐
devkit CLI ────────────────┼── HTTP over a unix socket ──▶ devkitd (runs as you)
devkit mcp (stdio MCP) ────┘                                ├─ proxy     127.0.0.1:80/443, TLS by SNI
                                                            │    ├─ static files
                                                            │    ├─ PHP → FastCGI → php-fpm pool per version (+ Xdebug pool)
                                                            │    ├─ Python → granian per site
                                                            │    ├─ dev servers and services → their port
                                                            │    └─ share listener for cloudflared
                                                            ├─ DNS       127.0.0.1:5354, *.test → 127.0.0.1
                                                            ├─ CA        name-constrained to .test
                                                            ├─ supervisor: PHP, Python, dev servers, processes, services, cloudflared
                                                            ├─ requests  in-memory ring buffer per site
                                                            ├─ dumps     loopback collector fed by a PHP prepend file
                                                            └─ engine    config, sites, runtimes, services, sharing

Processes

Section titled “Processes”
  • devkitd is a launchd job (app.getdevkit.daemon) that runs as the logged-in user. launchd opens 127.0.0.1:80 and :443 and passes the sockets to it. It serves an HTTP API on ~/Library/Application Support/DevKit/run/devkitd.sock.
  • DevKit.app is the window and menu bar icon. It holds no state: everything it shows comes from devkitd, and it gets updates as server-sent events.
  • devkit is the CLI, the MCP server, and (as php and composer symlinks) the terminal shims. Each is a thin client of the same API.

A request to https://shop.test

Section titled “A request to https://shop.test”
  1. The browser asks the system resolver for shop.test. /etc/resolver/test sends the query to devkitd’s DNS server, which answers 127.0.0.1.
  2. The browser connects to 127.0.0.1:443. devkitd picks the certificate for shop.test by SNI, issuing it from the local CA the first time.
  3. The proxy records the request and routes it by site type: static files from disk, PHP through FastCGI to the pool for the site’s version, Python and dev servers by proxying to their port, services by proxying to theirs.
  4. PHP pools, Python workers and dev servers start on the first request and are supervised from then on.

Shared requests

Section titled “Shared requests”

cloudflared connects out to Cloudflare and forwards visitors to a separate share listener on loopback. Only that listener treats requests as HTTPS from the outside: it checks the password and IP allowlist, sets the public host for PHP, and rewrites .test addresses in redirects to the public one. Regular .test traffic never trusts forwarded headers.

Code

Section titled “Code”
Crate What’s in it
devkit-core Everything: config, sites and detection, proxy, DNS, CA, supervisor, runtimes, services, sharing, dumps, requests, the API
devkitd Starts the core subsystems and serves the API
devkit-cli The devkit command, MCP server and shims
src-tauri The desktop shell: windows, tray, OS integration; no domain logic