A zero-copy FTP daemon built for speed, correctness, and portability.
Runs anywhere POSIX runs. Saturates Gigabit. Ships a console payload too.

Overview · Performance · Features · Best Setup · Build · Running · Configuration · ZHTTP

The C code is split into responsibility-based modules (ftp, http, transfer, archive, runtime, platform, and app) rather than a flat src//include/ namespace. Generated assets live under build/, not in the source tree. See docs/architecture.md for the dependency rules and layout.

zftpd is a high-performance FTP server written in C11. It was designed around a single idea: the data path should be as fast as the hardware allows, with no unnecessary work anywhere between file and socket.

In practice, this means using sendfile where the OS supports it, keeping the hot path free of allocations, and handling TCP backpressure correctly so the pipe never stalls under load. The result is an FTP daemon that saturates a full Gigabit Ethernet link in both directions — on Linux, macOS, or any POSIX-compliant system — without any client-side tuning.

The same binary model also targets PS4 and PS5 as console payloads, with on-screen notifications and an optional browser-based file explorer. This is an extension of the same codebase, not a fork — the POSIX foundation is identical.

Philosophy
  ├── Keep the data path fast          →  sendfile fast path, zero-copy where available
  ├── Handle TCP correctly             →  partial sends, EINTR, backpressure-aware buffers
  ├── Stay portable                    →  C11, POSIX, standard toolchain
  ├── Be predictable under load        →  no dynamic allocation per transfer, no surprises
  └── Extras are opt-in               →  encryption, rate limiting, web UI — all compile-time

zftpd saturates a full Gigabit Ethernet link — ~117 MB/s sustained in both directions.

This is the physical ceiling of a 1 GbE connection. It is achieved out of the box, with no kernel tuning required.

  Benchmark — single stream, wired 1 GbE, plain transfer

  Download  ████████████████████████████████████████████  117 MB/s
  Upload    █████████████████████████████████████████     108 MB/s
                                                          ────────
  Physical ceiling (1 GbE)                                125 MB/s

What makes it fast:

On encryption: enabling AUTH XCRYPT (ChaCha20) disables sendfile and switches to buffered I/O. Throughput becomes CPU-bound. For maximum speed on a trusted network, use plain transfers — that is what sendfile is there for.

zftpd performs at the physical limit of your network. The bottleneck is almost always the medium, not the software. Wi-Fi is the bottleneck — even Wi-Fi 6 introduces retransmissions and variable latency that collapse sustained FTP throughput. Use a wired connection.

The optimal topology is a direct Ethernet cable between source and destination, eliminating every unnecessary hop:

  [Source machine]
        │
  Ethernet cable
        │
  [Destination machine]

If a switch is needed, any Gigabit switch works. Avoid powerline adapters and MoCA bridges — they introduce jitter that disrupts sustained transfers.

Assign static IPs on both ends (e.g. 192.168.100.1 / 192.168.100.2). This removes DHCP latency and keeps the setup fully deterministic.

Things that matter on the client side:

• Transfer mode must be Binary (TYPE I). zftpd defaults to Binary, but a misconfigured client can override this silently — always verify.
• Use passive mode (PASV). It's the default and works cleanly behind NAT and firewalls. Active mode requires the server to reach back to the client and is frequently blocked.
• Enable parallel connections for large directory trees. FileZilla exposes this under Site Manager → Transfer Settings. It will not increase single-file speed, but dramatically reduces total time for many small files.
• Disable client-side CRC or integrity checks if offered. TCP guarantees delivery; checksumming again adds latency for no benefit.

zftpd reaches full Gigabit speed with default kernel parameters. If you are feeding a very fast NVMe drive into the network and want to raise the ceiling further:

# Raise socket buffer limits — run as root, optional
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

To make these persistent, add them to /etc/sysctl.conf.

  Upload speed to internal storage (wired 1 GbE, measured across multiple consoles)

  FW  4.03   ████████                                      ~20 MB/s
  FW  8.60   ████████████████████                           ~50 MB/s
  FW  9.00   ██████████████████████████████████              ~85 MB/s
  FW 10.00   ████████████████████████████████████████████   ~113 MB/s
                                                             ────────
  Physical ceiling (1 GbE)                                   125 MB/s

Make targets (host auto-detection, best-effort toolchains):

• make — build default target (Linux on Linux host, macOS on macOS host) release.
• make release-all — release build per platform detected (macos, linux, ps3, ps4, ps5).
• make debug-all — debug build per platform detected.
• make release-matrix — release build per platform and variant ENABLE_ZHTTPD=0/1, producing ELF/BIN dove applicabile.
• make TARGET=<platform> BUILD_TYPE=<release|debug> [ENABLE_ZHTTPD=0|1] clean all — build singolo.

Useful Makefile variables:

• TARGET: linux, macos, ps3, ps4, ps5 (auto su host). Case-insensitive.
• BUILD_TYPE: release (default), debug.
• ENABLE_ZHTTPD: 1 abilita web UI zhttp (default 0 su console, 1 su PC). Influenza naming: es. zftpd-ps5-zhttp-v1.3.0.bin.
• ARTIFACT_PREFIX: prefisso binari (default zftpd).
• ffi_langs: opzionale, per build dei binding FFI.

Output naming (release):

• ELF: build/<target>/release[/ -zhttp]/zftpd-<platform-tag>[-zhttp]-v<version>.elf
• BIN (console): ... .bin

Execution (binaries host):

./build/macos/release/zftpd-macos-$(uname -m)-v1.3.0 -p <port> -d <root>
./build/linux/release/zftpd-linux-$(uname -m)-v1.3.0.elf -p <port> -d <root>

Supported options:

• -p <PORT> (default 2121)
• -d <DIR> root FTP
• -h help

Output artifacts are versioned and platform-tagged, placed in build/<target>/<build_type>/.

# Targets
make TARGET=linux
make TARGET=macos
make TARGET=ps4
make TARGET=ps5

# Modifiers
make TARGET=linux BUILD_TYPE=debug
make TARGET=linux ENABLE_ZHTTPD=1     # enable web UI (off by default on POSIX)
make TARGET=ps5   ENABLE_ZHTTPD=0     # disable web UI (on by default on console)

# Tests (POSIX only)
make TARGET=linux test
make TARGET=macos test

PS4 and PS5 zhttp builds use the maintained PacBrew ports of libcurl (PS5 also libnfs). The downloader supports HTTP/HTTPS/FTP/FTPS and nfs:// NAS sources; HTTPS certificate verification stays enabled and the PacBrew Mozilla CA bundle is embedded into the payload at build time. See docs/dependencies.md.

PS5 zhttp releases also accept magnet:? links. They use a native libtorrent-rasterbar engine inside the payload; no companion computer is required. For local PS5 builds, install a PS5 SDK, then run bash tools/build_ps5_libtorrent.sh "$PS5_PAYLOAD_SDK" followed by make TARGET=ps5 ENABLE_LIBTORRENT=1 clean all. The release workflow builds this dependency automatically.

PS5 extracts ZIP archives with its built-in reader. To enable other formats supported by libarchive, install PacBrew ps5-payload-libarchive in the PS5 SDK and build with make TARGET=ps5 ENABLE_LIBARCHIVE=1. ZIP files continue to use the built-in reader in that build.

PS4 builds detect the PacBrew package through the target toolchain only (orbis-pkg-config / orbis-curl-config inside PS4_PAYLOAD_SDK, or the OPENORBIS environment), never through the host's libcurl. When the package is missing the downloader is disabled at build time and the rest of zftpd is unaffected; the same behaviour is available explicitly with ENABLE_LIBCURL=0. Override PS4_PKG_CONFIG, PS4_CURL_CONFIG and PS4_CA_BUNDLE to point at a custom install.

Links pasted into the Transfers view line up in a FIFO queue: TRANSFER_MAX_CONCURRENT downloads run at a time (2 by default, override at build time with -DTRANSFER_MAX_CONCURRENT=<n>) and the rest wait, showing their position. Queued jobs can be held back or cancelled before they ever start; up to TRANSFER_MAX_ACTIVE (16) jobs are tracked.

HTTP/FTP/NFS downloads write to <name>.zftpd.part and rename it after fsync(). Magnet downloads write a <name>.zftpd.part directory containing the torrent files; the directory is renamed after every piece is verified. Download status, destination and progress are recorded atomically in /data/zftpd/transfers.state (falling back to /tmp/zftpd/). BitTorrent resume data is stored alongside that state file. On startup zftpd restores the visible list and resumes unfinished jobs from the bytes already on disk. Paused jobs stay paused, and failed jobs remain visible for retry. The Transfers view can delete a saved partial and its record, or use Start over to delete it and start the same link from zero. Removing a completed record leaves the completed file untouched.

./build/linux/release/zftpd-linux-<arch>-v<version>.elf [-p <port>] [-d <root>]

./build/macos/release/zftpd-macos-<arch>-v<version> [-p <port>] [-d <root>]

Send .bin to your payload loader, or .elf if the loader accepts ELF directly.
On startup: on-screen notification displays IP and port.

Send .bin or .elf depending on your loader.
On startup: FTP: <ip>:<port> notification.

All configuration is compile-time, in include/ftp/ftp_config.h.

ZHTTP is a lightweight HTTP server embedded in zftpd that serves a browser-based file explorer. It allows browsing, downloading, and optionally uploading files from any browser on the local network — no FTP client required.

Once the daemon is running, open http://<ip>:<port>/ — the HTTP port mirrors the configured FTP port.

Upload support is enabled automatically alongside ZHTTP (ENABLE_WEB_UPLOAD=1).

Security: ZHTTP has no authentication beyond network access. It is designed for local-network use. Do not expose it on a public interface.

After console Rest Mode, ZHTTP auto-reconnects via /api/status (see docs/restmode.md).

Custom console toasts are available via GET /api/notify?text=Hello (useful for Home Assistant and similar local automation — see docs/API.md).

The System view also drives the hardware: fan threshold, network-listener restart and Blu-ray eject (POST /api/system/eject, hidden on Digital Edition consoles). The eject path comes from BD-EJ.

Downloads and previews send the raw file bytes. Console SELF containers can be requested decrypted instead, exactly like the FTP path does: enable Settings → Downloads → Decrypt protected files (or pass ?decrypt=1 to /api/file/get). The kernel pager is swapped in for that transfer only, so every other file — and every other client — keeps getting the on-disk bytes untouched.

Selecting many items (folders included) offers Download as ZIP: the archive is built while it streams (/api/archive/zip), so nothing is written to the console and even multi-gigabyte selections need no free space.

I would like to express our sincere thanks to:

• hippie68 — for the PS4 FTP reference implementation
• John Törnblom — for the PS5 payload framework
• Drakmor — for the inspiration in the implementation of PFR / CPTO / COPY
• The PlayStation homebrew community — for testing, feedback, and ongoing support

Special thanks to M///Class for contributing to the project through testing and for the steady commitment shown in following its development.