The dry version.

Jenni in one sentence.

A self-hosted download server for versioned software releases — as ZIP, with a changelog, a virus-scan badge, anonymous statistics, and a JSON API. Single admin, small, fast, transparent.

She runs in production at jenni.noschmarrn.dev, ships every release of every project in this stack since the start of 2026, and is the source of the JSON your apps poll when they ask "is there a new version?".

Who Jenni is for.

Not for: multi-user SaaS, paid-download marketplaces with checkout, or massive multi-GB binaries. Multi-GB releases work but are not the sweet spot.

What Jenni doesn't do, and why.

Where Jenni fits next to other release tools.

Each of these tools fits a different shape of project. Jenni is the answer when you want one URL per software under your own domain, automated update endpoints across multiple platforms (not only WordPress), and the freedom to add module catalogs or a wp.org bridge without gluing four services together. The other tools win on platform discoverability or built-in edge caching — pick the one that matches what you actually need.

Four shapes of project, one binary.

All four types share the same release table, the same scan pipeline, the same authentication, the same statistics, and the same audit log. The difference is in the public URL shape and the activation rules.

Four states a project can be in.

Status changes are recorded in the audit log. Releases inside any project are soft-deleted — they leave the active release set but stay in the database, recoverable from the admin UI for as long as you want.

What every upload goes through.

1. Magic-byte sniff. The first bytes of the uploaded file must match the ZIP magic. Filename extension is not trusted.
2. Zip-slip protection. Each entry's resolved path must stay inside the extraction root. Symlink and absolute-path entries are rejected.
3. Zip-bomb cap. Total uncompressed size is capped at 500 MB by default. Configurable per-instance.
4. ClamAV scan. Every upload is scanned against the local ClamAV daemon. Strict mode is the default: a scanner error aborts the upload. Scan status (clean / infected / error / unscanned) is part of the public API and the info page.
5. SHA-256 hash. Computed once on disk, returned in the API, displayed on the info page, embeddable in widgets.
6. Atomic activation. A successful upload writes to a versioned directory; activation is a single symlink swap. There is no read/write race on the active release.

Account and transport hardening

• Argon2id for password hashing (argon2-cffi).
• Login rate limit: 5 attempts per minute per IP, including successful logins (defends user enumeration).
• TOTP-2FA is mandatory for the admin: enrolment with QR + manual secret, 10 single-use recovery codes (Argon2id-hashed), TOTP secret encrypted at rest via HKDF(SECRET_KEY)→Fernet. Login is constant-time — a dummy verify runs on the user-not-found path so timing can't enumerate accounts.
• Step-up TOTP on writes: a fresh TOTP code is cached for 5 minutes for ordinary writes; destructive actions (master-password, signing-key, trust-list operations) demand an inline code per submit with no cache.
• Public route rate limit: 60 GET requests per minute per IP, in-memory sliding window.
• CSRF tokens on every admin form.
• Session cookies: HttpOnly, Secure, SameSite=Lax, signed via itsdangerous.
• HTTPS-only behind a reverse proxy with --proxy-headers.
• WordPress SVN credentials are encrypted at rest with Argon2id-stretched master-password + Fernet. A reset wipes all stored creds.

Container hardening

• Runs as UID 10001, never root.
• read_only: true root filesystem.
• cap_drop: [ALL].
• no-new-privileges security option.
• Writable mounts only for data/ and downloads/.

Daily defence

rescan-all is a CLI command intended to run nightly. It re-checks every existing release against the current ClamAV signature set, so a release that was clean on day one but matches a signature added later flips to infected in the public API the next morning.

Want the dated, per-phase ledger? The security changelog lists every hardening choice with the deploy date it went live on production — from Argon2id and ZIP-slip in the MVP, through the wp.org SVN bridge and ClamAV strict mode, to Ed25519 manifests and the offline trust anchor. Same machine, no marketing prose.

What's actually inside the binary.

Sizing, deployment, backup.

Every endpoint, with response shape.

All endpoints return UTF-8 JSON unless noted otherwise. Timestamps are ISO-8601. Hashes are hex-encoded SHA-256. Base URL throughout: https://jenni.download.

[
  {
    "slug": "breznflow",
    "name": "BreznFlow",
    "description": "Short description",
    "current_version": "1.2.3",
    "size_bytes": 184320,
    "sha256": "abc123…",
    "uploaded_at": "2026-05-09T11:23:00",
    "download_url": "https://jenni.download/breznflow"
  }
]

{
  "slug": "breznflow", "name": "BreznFlow",
  "current_version": "1.2.3",
  "size_bytes": 184320,
  "sha256": "abc123…",
  "uploaded_at": "2026-05-09T11:23:00",
  "download_url": "https://jenni.download/breznflow",
  "changelog": "## 1.2.3\n- Fix: …",
  "changelog_html": "<h2>1.2.3</h2><ul><li>Fix: …</li></ul>",
  "scan_status": "clean",
  "scanner_name": "clamav",
  "scanner_version": "1.4.3",
  "scanned_at": "2026-05-09T11:23:05",
  "scanner_signature_date": "2026-05-09T08:00:00"
}

{
  "version": "1.0.4",
  "size_bytes": 107226,
  "sha256": "d09e7e20442b789a4890beb2a8b2dd23a0adec62030d80a1828d533647eda13e",
  "download_url": "https://jenni.download/breznflow",
  "scan_status": "clean",
  "scanned_at": "2026-05-09T02:03:20",
  "scanner_name": "clamav",
  "scanner_version": "1.4.3",
  "scanner_signature_date": "2026-05-08T08:28:30"
}

Signing & trust

Endpoints that carry Ed25519 signatures over canonical JSON payloads. The signature is base64-encoded; the payload itself is the source of truth — recompute its canonical form on the client side, do not trust whitespace or key ordering on the wire. The full client-verification protocol is at jenni.download/trust.

{
  "trust": {
    "trust_version": 1,
    "expires_at": "2028-05-12T20:29:04.108727Z",
    "signed_at":  "2026-05-13T20:29:04.108727Z",
    "valid_keys": [
      {
        "key_id":     "5af2613e6e92c56d",
        "pubkey_b64": "mg6FbywzvR…",
        "valid_from": "2026-05-13T20:29:04.108727Z"
      }
    ],
    "revoked_keys": []
  },
  "signature": "BASE64 — Ed25519 over canonical(trust) with root privkey"
}

{
  "algorithm":  "ed25519",
  "pubkey_b64": "mg6FbywzvR…",
  "key_id":     "5af2613e6e92c56d",
  "created_at": "2026-05-13T14:01:46"
}

{
  "manifest": {
    "project":    "breznflow",
    "version":    "1.2.3",
    "sha256":     "abc123…",
    "size_bytes": 184320,
    "counter":    7,
    "signed_at":  "2026-05-14T09:21:33.451Z",
    "key_id":     "5af2613e6e92c56d",
    "url":        "/breznflow/v/1.2.3"
  },
  "signature": "BASE64 — Ed25519 over canonical(manifest) with the signing privkey of key_id"
}

{
  "collection": {
    "slug": "schneespur-modules",
    "name": { "de": "Schneespur-Module", "en": "Wintertrace Modules" },
    "description": { "de": "Erweiterungen für die Schneespur-App",
                     "en": "Add-ons for the Wintertrace app" },
    "generated_at": "2026-05-27T11:23:00Z"
  },
  "modules": [
    {
      "slug": "schneespur-export",
      "name": { "de": "Export-Modul", "en": "Export module" },
      "description": { "de": "GPX/CSV-Export", "en": "GPX/CSV export" },
      "primary_locale": "de",
      "locales": ["de", "en"],
      "current_version": "0.4.1",
      "category": { "de": "Export", "en": "Export" },
      "tags": [ { "de": "GPX", "en": "GPX" }, { "de": "CSV", "en": "CSV" } ],
      "image_url": "https://jenni.download/schneespur-export/icon",
      "author_name": "Acme GmbH",
      "author_url": "https://example.com",
      "download_url": "https://jenni.download/schneespur-export",
      "info_url": "https://jenni.download/schneespur-export/info",
      "sha256": "abc123…",
      "size_bytes": 51200,
      "released_at": "2026-05-08T09:00:00Z",
      "manifest": {
        "schema_version": 1,
        "type": "plugin",
        "license": "GPL-3.0-or-later",
        "minimum_app_version": "2.0.0",
        "capabilities": ["export"],
        "dependencies": []
      }
    }
  ]
}

Author API (authenticated)

For third parties who submit modules into one of your collections. Auth is a Bearer token bound to exactly one collection (Authorization: Bearer <token>); tokens are created, paused, and soft-revoked in the admin under /admin/projects/<collection>/api-tokens (every action step-up-TOTP-gated). Submissions land as draft — publication is the operator's call, or automatic per a collection's auto_publish flag. The scan and Ed25519-signing pipeline is identical to the admin UI: there is no second code path (see Phase B). Every write is scope-checked — a token can only touch modules in its collection, otherwise 403.

Direct download URLs

These return application/zip, not JSON. Each download increments the anonymous counter.

Embed and info endpoints

What's done, what's still cooking.

Shipped and live

• Phase 1 — MVP. Upload, auth, public download, JSON API.
• Phase 2 — comfort. Statistics, audit log, status-change UI, CSV export, rate limits.
• Phase 3 — embed. Widget, info page, public-side i18n DE/EN.
• Phase 4 — trust badge. ClamAV pipeline, trust-badge SVG, daily re-scan.
• Phase 5.1 — WordPress bridge, part one. Per-plugin SVN settings, master-password-encrypted credentials.
• Phase 5.2 — WordPress bridge, part two. Pre-flight checks (PHPCompatibility, plugin-check, PHPCS), atomic trunk + tags/<version> commit as one revision, diff preview before push.
• Phase 5.3 — wp.org asset workflow. Separate SVN commit against the wp.org assets/ path for banner, icon, screenshots — stage-and-batch pattern with diff preview.
• Phase 6 — module catalogs. Third project type (module_collection) and fourth (module), ETag-cached JSON catalog at /api/modules/<slug>, icon endpoint with sha256 ETag, cascade-protected deletion.
• Phase 7 — Ed25519 release manifests. Per-release signed manifest with rollback counter, signed timestamp, signed SHA-256. Server-side signing key management with encrypted-at-rest privkey. Reference verifier in the repo.
• Phase 8 — offline trust anchor. Operator-laptop CLI (tools/trust-tool/) signs trust.json with a root key that never touches the server. Signing-key rotation and revocation without client code updates. Trust-list expiry and replay protection. Full protocol →
• Phase 9 — multilingual content. Project and module names, descriptions, changelogs, categories, and tags become i18n objects ({"de": …, "en": …}) with a per-project locale list and primary locale. Public pages and the catalog resolve language independently of the admin chrome.
• Phase 10 — admin hardening. Mandatory TOTP-2FA, 10 single-use recovery codes, step-up TOTP for write actions, constant-time login, session_epoch force-re-auth.
• Phase 11 — module.json contract. A generic, server-validated author manifest format with a public JSON Schema at /api/schema/module-json.
• Phase 12 — headless schema cleanup. Module screenshots with i18n captions, author / support URLs, pre-rendered changelog HTML cached at write-time.
• Phase B — shared core layer. Admin UI and the author API call the same in-process app/core/ use-cases — one validation and scan path, no self-HTTP.
• Phase C — public author API. Third parties submit modules through an authenticated REST API (collection-bound bearer tokens); the operator reviews and approves.
• Phase C.1 — API-key admin. Collection-scoped token management in the UI: create, pause / resume, soft-revoke — all step-up-TOTP-gated.

Still cooking

• Self-install packages — the actual open-source release: setup wizard, documented ENV defaults, sample Caddyfile, security CHANGELOG.
• JenniHUB — a standalone self-service marketplace frontend on top of the author API (separate project): developers manage their own uploads, the operator only approves.
• Hardware-token / HSM for the root key — deliberately out of scope for the current phase, on the menu for later.

Where Jenni stands legally.

Jenni is currently a personal project run in production for the operator's own releases. An open-source release under MIT is planned, gated on the self-install story being good enough for someone who isn't the operator to stand her up in an afternoon.

For now: if you want to run her, talk to me. If you want to evaluate her without running her, the live reference is jenni.noschmarrn.dev and every API endpoint above is reachable there.

Questions, integration ideas, audit notes — info@noschmarrn.dev.