vaggeliskls

Posted on Mar 28

Self-Hosted File Servers: From FTP to WebDAV to Cloud-Native

#selfhosted #docker #devops #kubernetes

Every developer hits the same question eventually: where do I put the files?

Maybe it's backup artifacts from a CI pipeline. Maybe it's a shared folder for a small team. Maybe you're tired of paying per-seat for Dropbox and want something you actually control.

The self-hosted file server space has matured a lot, but the sheer number of options can be overwhelming. This article breaks down the main approaches, when each one makes sense, and for the WebDAV path, walks you through two open-source projects I maintain that cover local and cloud storage scenarios.

The Landscape: How Do You Want to Serve Files?

Before picking a tool, it helps to understand the categories. Self-hosted file sharing broadly falls into four buckets:

1. Traditional File Protocols (FTP/SFTP/SMB)

The old guard. FTP and SFTP are battle-tested and universally supported. SMB (Samba) is the default for Windows network shares. They work, but they come with baggage: FTP sends credentials in plaintext (unless you configure FTPS), SMB is chatty on the network and painful to expose over the internet, and neither protocol plays well with modern auth flows like OAuth or LDAP without extra tooling.

Best for: LAN-only file sharing, legacy system integration, printer/scanner destinations.

2. Full-Featured Cloud Platforms (Nextcloud, Seafile, FileRun)

These are the "replace Google Drive" solutions. Nextcloud in particular has become the go-to self-hosted platform, offering file sync, calendars, contacts, office document editing, and hundreds of plugins. Seafile focuses more narrowly on file sync with excellent delta-sync performance. FileRun takes a lighter approach, letting you manage files directly on the filesystem with a polished web UI.

The trade-off is complexity. Nextcloud needs a database, a PHP runtime, and regular maintenance. Seafile's block-based storage means your files aren't directly accessible on the filesystem. These platforms are excellent when you need the full suite, but they're overkill if you just want a folder accessible over the network.

Best for: Teams that need a full collaboration platform, users migrating from Google Workspace or Dropbox.

3. Sync-First Tools (Syncthing, Resilio)

These aren't servers in the traditional sense. They're peer-to-peer sync engines. Syncthing is fully open-source and does one thing well: keep folders in sync across devices without a central server. There's no web UI for browsing files, no user management, no access control. It's a pipe, not a platform.

Best for: Keeping personal devices in sync, distributed backups, scenarios where no central server is desired.

4. WebDAV

And then there's WebDAV, the protocol that sits in the sweet spot between "too simple" and "too complex." WebDAV extends HTTP with file operations: upload, download, move, copy, lock, list directories. Every major OS supports it natively (mount it as a network drive on Windows, macOS, or Linux without installing anything). Backup tools like Rclone, Restic, and Duplicati speak WebDAV out of the box. Office applications can open and save documents directly over WebDAV URLs.

Because it's just HTTP under the hood, you get all the benefits of the HTTP ecosystem: reverse proxies, TLS termination, OAuth/OIDC integration, load balancing, caching headers. All of these work without any protocol translation.

Best for: Lightweight file sharing with real access control, backup destinations, CI/CD artifact storage, mobile file access, mounting remote storage as a local drive.

Why I Built Two WebDAV Servers

I've been running WebDAV servers in various setups for a while. My original project, webdav-server, started as a simple Docker container wrapping Apache httpd with WebDAV modules. Over time it grew to support per-folder permissions, multiple auth methods, and a bunch of operational features.

But there was a gap: what if your files live in S3 or Google Cloud Storage? Apache's WebDAV module only works with local filesystems. So I built a second project, cloud-webdav-server, written in Go, that presents cloud object storage as a WebDAV drive.

Here's how the two compare:

	webdav-server	cloud-webdav-server
Runtime	Apache httpd (Docker)	Go binary (distroless Docker, ~10 MB)
Storage	Local filesystem	Local, Amazon S3/MinIO, Google Cloud Storage
Auth	Basic, LDAP, OAuth/OIDC, LDAP+Basic fallback	Basic, LDAP, OpenID Connect (Bearer)
Permissions	Per-folder, per-user, exclusions	Per-folder, per-user, exclusions
Kubernetes	OCI Helm chart	OCI Helm chart
Best for	On-premise file sharing, NAS replacement	Cloud-native setups, S3/GCS frontends

Both share the same FOLDER_PERMISSIONS syntax, so the mental model transfers between them.

Getting Started with webdav-server

👉 github.com/vaggeliskls/webdav-server
📖 Full documentation

The quickest way to get a WebDAV server running:

1. Create a .env file:

BASIC_AUTH_ENABLED=true
BASIC_USERS="alice:alice123 bob:bob123"
FOLDER_PERMISSIONS="/shared:*:ro,/alice:alice:rw,/bob:bob:rw"

2. Create a docker-compose.yml:

services:
  webdav:
    image: ghcr.io/vaggeliskls/webdav-server:latest
    ports:
      - 80:8080
    volumes:
      - ./webdav-data:/var/lib/dav/data
    env_file:
      - .env

3. Run it:

docker compose up -d

That's it. Alice and Bob can both read /shared, but each can only write to their own folder. Folders are auto-created at startup.

Per-Folder Access Control

This is the feature that sets it apart from most WebDAV containers you'll find on Docker Hub. The FOLDER_PERMISSIONS variable uses a simple format:

/path:users:mode

Where users can be public (no auth), * (any authenticated user), specific usernames, or exclusions with !:

# Everyone can read /public, no login needed
# All authenticated users can read /shared except charlie
# Only alice and bob can write to /projects
FOLDER_PERMISSIONS="/public:public:ro,/shared:* !charlie:ro,/projects:alice bob:rw"

Authentication Options

You can enable one or more auth methods:

Basic Auth: simplest setup, users defined in the .env file with bcrypt hashing
LDAP: connect to Active Directory or any LDAP server for centralized user management
OAuth/OIDC: integrate with Keycloak, Okta, Azure AD, or any OpenID Connect provider
LDAP + Basic fallback: try LDAP first, fall back to local users if LDAP auth fails

What's New Since v1

Since I first wrote about this project, several features have been added:

Per-folder permissions with user inclusion/exclusion
Public folders that require no authentication
Read-only vs read-write mode per folder (configurable HTTP methods)
CORS support for web clients
Health check endpoint (/_health) for load balancer probes
LDAP + Basic fallback authentication
Security test suite for validating access control
Full documentation site at vaggeliskls.github.io/webdav-server

Getting Started with cloud-webdav-server

👉 github.com/vaggeliskls/cloud-webdav-server

If your files live in S3 or GCS, this project lets you access them over WebDAV without syncing anything locally.

Local storage (same idea, lighter runtime):

STORAGE_TYPE=local
LOCAL_DATA_PATH=/data
BASIC_AUTH_ENABLED=true
BASIC_USERS="alice:alice123"
FOLDER_PERMISSIONS="/files:*:rw"

Amazon S3 / MinIO:

STORAGE_TYPE=s3
S3_BUCKET=my-bucket
S3_REGION=us-east-1
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
FOLDER_PERMISSIONS="/files:*:rw"

Google Cloud Storage:

STORAGE_TYPE=gcs
GCS_BUCKET=my-bucket
GOOGLE_APPLICATION_CREDENTIALS=/run/secrets/sa.json
FOLDER_PERMISSIONS="/files:*:rw"

Then just docker compose up and mount http://localhost:8080/files/ as a network drive. Your S3 bucket is now a WebDAV folder.

The Go binary compiles into a ~10 MB distroless container that runs as a non-root user, lean enough for Kubernetes sidecars or edge deployments.

Kubernetes Deployment with OCI Helm Charts

Both projects ship with Kubernetes Helm charts distributed as OCI artifacts. This means you can deploy either WebDAV server to your cluster using standard Helm commands without adding a custom chart repository:

# Deploy webdav-server
helm install webdav oci://ghcr.io/vaggeliskls/charts/webdav-server

# Deploy cloud-webdav-server
helm install cloud-webdav oci://ghcr.io/vaggeliskls/charts/cloud-webdav-server

OCI-based Helm charts are pulled directly from the container registry, so you get the same versioning and distribution model as your container images. Override values with -f values.yaml or --set flags as usual.

Practical Use Cases

Here are some real scenarios where a WebDAV server fits perfectly:

Backup destination. Tools like Rclone, Restic, and Duplicati support WebDAV natively. Point them at your server and you have a self-hosted backup target with access control.

CI/CD artifact storage. Upload build artifacts with curl -T after a successful build, download them in downstream jobs. Give the CI bot write access and everyone else read-only:

FOLDER_PERMISSIONS="/artifacts:ci-bot:rw,/artifacts:*:ro"

Mobile file access. Apps like Solid Explorer (Android) and Documents by Readdle (iOS) can connect to WebDAV servers directly. No app-specific sync client needed.

Network drive replacement. Mount it on Windows (net use Z: http://server/files/), macOS (Finder > Connect to Server), or Linux (mount -t davfs). Native OS support, no client installation.

Document collaboration. LibreOffice and Microsoft Office can open and save files directly over WebDAV URLs. No download-edit-upload cycle.

Static file distribution. Serve public read-only assets (releases, datasets, documentation) without any authentication overhead. Combine with a reverse proxy for caching and HTTPS.

Choosing the Right Approach

Scenario	Recommended approach
Full Google Drive replacement with office editing, calendars, etc.	Nextcloud or Seafile
Syncing folders between personal devices	Syncthing
Lightweight file sharing with access control	webdav-server
Serving files from S3/GCS over WebDAV	cloud-webdav-server
LAN-only sharing with Windows machines	SMB/Samba
Legacy system integration	FTP/SFTP
CI/CD artifacts, backup targets, mobile access	webdav-server or cloud-webdav-server

There's no single right answer. It depends on what you're storing, who needs access, and how much infrastructure you want to manage. But if you need something between "raw FTP" and "full Nextcloud deployment," WebDAV hits a sweet spot that's worth considering.

DEV Community