A pastebin service built entirely in Mojo. Zero Python in the hot path: the HTTP server, WebSocket server, database layer, JSON serialisation, and routing are all Mojo code.
Live demo: mobin.fly.dev
- Backend: Mojo (flare HTTP + WS, sqlite, json, morph serde, uuid, tempo, envo, pprint)
- Frontend: Vanilla JS + nginx, live feed via WebSocket, auto-removal of expired pastes
- Infra: Docker Compose, single root
pixi.toml(monorepo), GitHub Actions -> Fly.io CD
graph TD
subgraph Browser
UI[HTML / JS frontend]
end
subgraph "Docker / Fly.io"
direction TB
NGINX[nginx :3000\nfrontend]
subgraph Mojo backend process
FORK[fork]
HTTP[HttpServer :8080\nREST API]
WS[WsServer :8081\nWebSocket feed]
end
SQLITE[(SQLite WAL\n/data/mobin.db)]
end
UI -->|HTTP GET /| NGINX
UI -->|REST API calls| HTTP
UI -->|ws://...:8081/feed| WS
FORK -->|parent| HTTP
FORK -->|child| WS
HTTP -->|per-request connection| SQLITE
WS -->|per-connection connection| SQLITE
pixi install # resolve + install all Mojo dependencies pixi run run-dev # start backend on :8080 (HTTP) and :8081 (WS)
Open http://localhost:8080. The backend serves the embedded frontend directly.
Or with Docker Compose:
docker compose up --build # Frontend: http://localhost:3000 # Backend: http://localhost:8080
| Guide | What it covers |
|---|---|
| Architecture | Process model, database design, URL routing, stats table |
| API Reference | REST endpoints, WebSocket feed, TTL options, curl examples |
| Development | Repo layout, pixi commands, environment variables, integration tests |
| Package Management | Why Pixi, dependency pinning, dependency graph |
| Deployment | Fly.io, VPS + Docker Compose, Caddy TLS, Litestream backup |
| Performance | Local and live benchmarks |
| Security | Security checklist and resilience |