WebDAV & FTP

Mount a site as a network drive over WebDAV, or expose it over FTP for clients and workflows that need it. Both give full write access to one site's files, with the same path and quota rules as every other write path.

WebDAV: mount a site as a drive

Enable WebDAV for the site (UI toggle, or set "webdav_enabled": true via the API), then mount https://sitebin.example.com/dav/<edit-id>/ — username anything, password = the edit password.

Windows: Explorer → "Map network drive" → the URL above.
macOS: Finder → Go → "Connect to Server…".

Or with rclone, one line:

rclone lsf :webdav: --webdav-url=https://…/dav/<edit-id>/ --webdav-pass=$(rclone obscure $PW)

WebDAV grants full write access — treat the mount URL + edit password like the edit URL itself.

Windows/macOS + plain HTTP → 401. The built-in WebDAV clients in Windows Explorer and macOS Finder refuse to send Basic-auth credentials over an unencrypted http:// connection, so mounting a local/HTTP-only instance fails with 401 (the password is never sent). This is a client policy, not a server rejection. Fixes: use an HTTPS instance (the normal production case — it just works), or a client that allows Basic-over-HTTP such as rclone, WinSCP, Cyberduck, or curl. On Windows you can also set HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel to 2 and restart the WebClient service. Windows Explorer also caps downloads at 50 MB by default (FileSizeLimitInBytes).

FTP

As an alternative to WebDAV, a site's files can be exposed over FTP. It is off by default and must be enabled both instance-wide (SITEBIN_FTP_ENABLED=true) and per site (toggle on the edit page, or "ftp_enabled": true). Then connect with any FTP client:

Username = the site's edit UUID
Password = the site's edit password

# list, upload, download (curl speaks FTP)
curl --user "$EDIT_ID:$PW" ftp://sitebin.example.com/
curl -T local.html --user "$EDIT_ID:$PW" ftp://sitebin.example.com/page.html
curl --user "$EDIT_ID:$PW" ftp://sitebin.example.com/index.html

Each session is confined to that one site's files, with the same path and quota rules as every other write path.

Plain FTP is unencrypted — username and password travel in clear text. Use it only on a trusted network, or configure FTPS with SITEBIN_FTP_TLS_CERT / SITEBIN_FTP_TLS_KEY. Like WebDAV, FTP grants full write access to the site.

Passive mode & Docker

FTP opens a second connection for each data transfer (LIST, upload, download). In passive mode (what clients use by default) the server tells the client which host and port to open that connection to — and getting this right through Docker is the part that trips everyone up. Two rules:

Publish the whole passive range 1:1. The container-internal port the server picks must be reachable under the same number on the host: -p 21:21 -p 21000-21010:21000-21010 (a 21000-21010:21000-21010 mapping, not a single port). Widen the range with SITEBIN_FTP_PASV_PORT_MIN/_MAX if you expect many concurrent transfers.
Set SITEBIN_FTP_PUBLIC_HOST to the address the client actually reaches — not the container's internal IP. Locally that's 127.0.0.1; in production it's your server's public IP or hostname (e.g. sitebin.example.com). If it's wrong, the control connection logs in and LIST/transfers then hang or fail — that symptom is almost always a wrong SITEBIN_FTP_PUBLIC_HOST or unmapped passive ports.

Because of all this, WebDAV (/dav/<edit-id>/, plain HTTPS, no extra ports) is the smoother remote-mount option; reach for FTP when a client or workflow specifically needs it.

← Deploy from CI Custom domains →