Forem: vaggeliskls

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

vaggeliskls — Sat, 28 Mar 2026 14:52:17 +0000

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.

Deploy a Secure Containerised WebDAV Server with Docker in Minutes

vaggeliskls — Tue, 16 Sep 2025 12:12:40 +0000

Deploy a secure, lightweight WebDAV server with Docker in minutes. This containerised solution supports Basic, LDAP, and OAuth authentication, making it ideal for self-hosted file sharing, backups, and enterprise remote access with minimal setup.

👉 Check it out on GitHub: vaggeliskls/webdav-server

📖 What is WebDAV?

WebDAV (Web Distributed Authoring and Versioning) is an extension of HTTP that lets you manage files on a server upload, download, edit, move, and share as if it were local storage. It’s widely supported across operating systems, backup tools, and mobile apps.

This project provides a modern, containerised WebDAV server that’s:

Easy to deploy with Docker 🐳
Flexible in authentication 🔐
Ideal for self-hosting and enterprise use 🏢

📦 Prerequisites

Before starting, ensure you have:

Docker version 20.0 or higher
Basic understanding of containers and WebDAV

🚀 Key Features

Effortless Deployment: Set up a fully operational WebDAV server quickly using Docker.
Flexible Authentication:
- Basic Authentication 🛡️
- LDAP Authentication 🛡️
- OAuth Authentication 🛡️
Proxy-Ready: Easily integrate with reverse proxies to add more authentication layers.
Authentication is Optional: The server runs without authentication by default, allowing flexibility for your setup.

🔧 Authentication Setup

You can enable various authentication mechanisms using environment variables in a .env file. Here’s how to configure each one:

🔐 Basic Authentication

Authentication is controlled via environment variables in a .env file.

BASIC_AUTH_ENABLED=true
BASIC_AUTH_REALM=WebDAV
BASIC_USERS=alice:alice123 bob:bob123

🔐 OAuth Authentication

OAuth authentication (example with Keycloak) configuration:

OAUTH_ENABLED=true
OIDCProviderMetadataURL="http://keycloak/keycloak-auth/realms/master/.well-known/openid-configuration"
OIDCRedirectURI="http://my-domain.local/redirect_uri"
OIDCCryptoPassphrase="randomly_generated_secure_passphrase"
OIDCClientID="webdav-client"
OIDCClientSecret="ABC123def456GHI789jkl0mnopqrs"
OIDCProviderTokenEndpointAuth="client_secret_basic"
OIDCRemoteUserClaim="preferred_username"
OIDCScope="openid email profile"
OIDCXForwardedHeaders="X-Forwarded-Host"

More examples with different identity providers can be found on the mod_auth_openidc GitHub page.

🔐 LDAP Authentication

LDAP integration for centralized user management:

LDAP_ENABLED=true
LDAP_URL=ldaps://ldap.example.com
LDAP_ATTRIBUTE=uid
LDAP_BASE_DN=ou=users,dc=example,dc=com
LDAP_BIND_DN=uid=admin,ou=users,dc=example,dc=com
LDAP_BIND_PASSWORD=securepassword

📑 WebDAV Methods and Access Control

Control allowed methods with the WEBDAV_OPERATIONS variable.

Method	Purpose
GET	Download a file or resource
OPTIONS	Discover server-supported methods
PROPFIND	List directory contents, get resource metadata
PUT	Upload a file
DELETE	Delete a file or resource
MKCOL	Create a new collection (folder)
COPY	Copy a resource
MOVE	Move or rename a resource
LOCK	Lock a resource
UNLOCK	Unlock a resource
PROPPATCH	Set or remove resource properties
REPORT	Query for information (advanced WebDAV clients)
PATCH	Partial update of a resource
HEAD	Retrieve headers only (no body)
POST	Submit data (rarely used in WebDAV, sometimes for locking)

⚡ Usage Example

1) Create a .env

WEBDAV_OPERATIONS="GET OPTIONS PROPFIND"
LDAP_ENABLED=false
OAUTH_ENABLED=false
BASIC_AUTH_ENABLED=false

2) Create a docker-compose.yaml file

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

3) Run the server

docker compose up -d

4) Access it Open: http://localhost:8080

This example runs an unauthenticated server. For production, enable HTTPS and authentication.

📚 References

Rehosting Bitnami Secure Images with Specific Tags

vaggeliskls — Mon, 15 Sep 2025 12:35:30 +0000

Bitnami recently updated its policy, restricting direct access to their secure container images (discussion here). This change impacts automated workflows, CI/CD pipelines, and production deployments that rely on Bitnami images and Helm charts.

To address this, the Bitnami Secure Hosting repository provides a workflow to rehost and tag secure images for stable, policy-compliant usage.

👉 Check it out on GitHub: bitnami-secure-hosting

🔍 The Problem

Bitnami’s new policy introduces:

“A focused set of more hardened, more secure images. These free images are intended for development and are only available on the latest tag. You can find them at bitnamisecure on Docker Hub
.”

This approach creates a major issue for developers and production teams:

🏷️ Only latest is available — you cannot select a specific version.
🔄 Reproducibility breaks — the same latest tag may change without notice.
⚠️ CI/CD pipelines become unstable, since updates may introduce unexpected changes.
🛑 Production systems lose reliability, because you can’t lock deployments to a tested version.

In practice, this makes the “focused, secure images” unstable and impractical for anyone who needs predictable builds, controlled upgrades, or long-term maintenance.

🎯 The Goal

The purpose of the repository bitnami-secure-hosting is to:

Reverse-engineer Bitnami latest tag creation.
Tag each secure image with a specific version for better tracking.
Enable controlled testing of each image before deployment.

This ensures that teams can continue using Bitnami images safely without relying on a moving latest tag, reducing production risks.

💡 The Solution

The Bitnami Secure Hosting repository solves these problems by:

Fetching the latest secure images from Bitnami's official secure registry (docker.io/bitnamisecure).
Inspecting and pinning each image to a specific product version using fields like APP_VERSION.
Rehosting images to a self-managed registry (ghcr.io/vaggeliskls by default) for secure, predictable access.
Automating the workflow to ensure images remain up-to-date and safe for production.

This approach provides control, compliance, and reliability for teams that cannot rely on latest tags.

🚀 How It Works

Pull images from the official Bitnami secure registry.
Inspect images to determine the product version.
Re-tag images according to their version.
Push images to your self-managed registry for safe usage.
Automated updates ensure the registry stays current without manual intervention.

✅ Conclusion – My Point of View

From my perspective, Bitnami’s new approach cannot be considered production-ready. Even their own documentation clarifies that the free, secure images are intended only for development use.

This policy shift feels like a setback for the open-source community. We’ve already seen similar moves from Docker, which introduced premium hardened images — raising the same concerns.

It makes me wonder:

🤔 Will official public images continue to be updated with the same frequency and security focus?
Or will the priority shift toward paid solutions while the community versions stagnate?

The open-source ecosystem we’ve relied on for years is starting to change, and not always for the better.

While there are alternatives to Bitnami images themselves, the real impact is deeper:

Kubernetes deployments
Helm charts in production
Automated CI/CD workflows

All of these depend heavily on predictable, versioned images. Without them, reproducibility and reliability suffer — especially at scale.

In short, this transition doesn’t just affect images, it creates long-term challenges for production-grade deployments in the open-source world.

Buttercup Password Manager for Startups 🛡️

vaggeliskls — Sun, 20 Oct 2024 17:24:39 +0000

In today's digital age, managing passwords securely is crucial for individuals and businesses alike. The Buttercup password manager offers a versatile solution, allowing users to store their vaults locally or utilize cloud services like Dropbox and Google Drive. However, for companies seeking to host their password management in-house, a custom WebDAV server can be an ideal solution.

🌐 Why Choose a WebDAV Server?

WebDAV (Web Distributed Authoring and Versioning) is a protocol that enables clients to manage files on remote servers. By setting up your own WebDAV server, you gain greater control over your data, enhancing security and privacy while ensuring compliance with organizational policies.

🔑 Key Features

Custom Authentication: The Buttercup WebDAV server supports both LDAP and Basic static authentication, making it suitable for small to medium-sized companies that need robust user management.management.
Docker Support: Deploying the WebDAV server with Docker is straightforward, allowing for quick setup and scalability. This ensures that your environment can grow with your business needs.

📥 Download the Buttercup Client

Before deploying the WebDAV server, don’t forget to download the Buttercup client from the official website. This client allows you to access and manage your vault seamlessly.

🚀 Getting Started

To deploy your Buttercup WebDAV server:

Clone the Repository: Start by cloning the Buttercup WebDAV server repository.
Configure Environment Variables: Edit the .env file to customize your setup. This includes configuring your authentication methods and any specific settings for your environment.
Launch the Server: Use Docker Compose to bring your server online with a simple command, enabling easy management of containers.
Access Your Vault: Open the Buttercup client, enter your server's URL, and authenticate with your chosen credentials. This grants you access to your securely stored passwords.

🔒 Secure Your Connection

For secure access, it's advisable to configure TLS/HTTPS using a reverse proxy like Traefik. This adds an extra layer of security, ensuring that your data remains safe during transmission and protects against potential attacks.

🎉 Conclusion

The Buttercup WebDAV server is a powerful tool for businesses looking to manage passwords securely in-house. By leveraging Docker and customizable authentication methods, you can create a tailored solution that meets your company's needs.

For more details and to get started, check out the GitHub repository and explore the WebDAV server documentation.

Pull images from private docker registry in Kubernetes cluster 🐳

vaggeliskls — Sat, 22 Jun 2024 20:49:26 +0000

When working with Kubernetes, especially for deploying applications, authenticating with private image repositories is often necessary. This process is crucial for AWS ECR registries and other Docker-related registries. This post introduces a Helm chart designed to simplify and streamline this authentication process, making your workflow smoother.

📦 Helm Chart Repository: oci://registry-1.docker.io/vaggeliskls/k8s-registry-auth

Remember to star ⭐ this Helm chart if you find it useful! More info available at GitHub.

Supported Image Registries 🌐

This Helm chart mainly supports AWS ECR registries, but it also includes support for other popular registries. Specifically, it has been tested with the following registries:

Amazon ECR
JFrog Artifactory
Nexus
Docker Hub

While it has not yet been tested with the following registries, initial support is available:

Harbor
IBM Cloud Container Registry

Furthermore, future support is planned for:

Google Artifact Registry
Azure Container Registry

It's important to note for those using AWS ECR registries that re-authentication is required every 12 hours. To address this, the Helm chart includes a cronjob that refreshes the login automatically, ensuring you are always authenticated to your registry.

Prerequisites 🛠️

Helm version 3 or higher must be installed on your system before proceeding.

Using the Helm Chart 🚀

Configuration

Configure the registry field to specify the target registry for authentication. You can set registry credentials in two ways:

Using an Existing Secret
Providing Static Username and Password in values.yaml

For examples for both AWS ECR and generic Docker registries, see the dedicated examples section.

Examples

AWS ECR

Assuming your Helm is set up correctly, use one of the following commands:

For existing secrets:

helm upgrade --install k8s-registry-auth oci://registry-1.docker.io/vaggeliskls/k8s-registry-auth  --set registry=123456789123.dkr.ecr.region.amazonaws.com --set awsEcr.enabled=true --set secretConfigName=secret-name

For static credentials:

helm upgrade --install k8s-registry-auth oci://registry-1.docker.io/vaggeliskls/k8s-registry-auth  --set registry=123456789123.dkr.ecr.region.amazonaws.com --set awsEcr.enabled=true --set registryUsername=username --set registryPassword=password

Replace 123456789123.dkr.ecr.region.amazonaws.com with your own AWS ECR registry URL. If you're using a specific version of this OCI repository, add --version 1.0.1.

Docker Based Registries Examples

For existing secrets:

helm upgrade --install k8s-registry-auth oci://registry-1.docker.io/vaggeliskls/k8s-registry-auth  --set registry=yourdomain.com --set docker.enabled=true --set secretConfigName=secret-name

For static credentials:

helm upgrade --install k8s-registry-auth oci://registry-1.docker.io/vaggeliskls/k8s-registry-auth  --set registry=yourdomain.com --set docker.enabled=true --set registryUsername=username --set registryPassword=password

Replace yourdomain.com with your registry's domain name.

Conclusion

Authenticating image registries doesn't have to be a painful process when deploying applications on Kubernetes. With this Helm chart, you can easily manage and automate this process

Windows GitHub Self Hosted Runner inside a Linux Container

vaggeliskls — Sat, 18 May 2024 15:00:30 +0000

With ever-increasing advancements in the world of CI/CD pipelines, innovation is inevitable. Welcome to the exploration of an efficient, cost-effective, and innovative approach to deploying self hosted GitHub Runner. This runner operates in a containerized Windows OS (x64) environment on a Linux system.

The approach leverages the strengths of Vagrant VM, libvirt, and Docker Compose, allowing seamless management of a Windows instance just like any Docker container. The takeaway is the creation of a plug-and-play solution, significantly enhancing convenience, optimizing resource allocation, and integrating flawlessly with existing workflows.

For those working in various dev-ops environments, this strategy provides a smooth and comprehensive solution that does not require prior knowledge of VM creation.

This guide is built upon the https://github.com/vaggeliskls/windows-github-custom-runner

📋 Prerequisites

Docker version 24 or higher
Docker-compose version 1.18 or higher

🚥 Authentication Methods for Self-Hosted

To authenticate your custom self-hosted runners, two methods are available:

Personal Access Token (PAT): A static, manually created token that provides long-term and secure access to GitHub. This token requires Read and Write access to the GitHub organization’s self-hosted runners.
Registration Token (TOKEN): A dynamic, short-lived token that is automatically generated by GitHub when creating a new self-hosted runner. This method offers a temporary but immediate solution for authentication.

⚠ Note: Only one of these authentication methods is needed. Choose the one that best suits your requirements.

🚀 Deployment Guide

1) Create/Update the environmental file .env

PAT: Personal access token from GitHub
TOKEN: Short lived Github token
RUNNER_URL: The URL of the GitHub that the runner connects to
RUNNERS: Number of runners
MEMORY: Amount of memory for the Vagrant image (in MB)
CPU: Number of CPUs for the Vagrant image
DISK_SIZE: Disk size for the Vagrant image (in GB)

Example with PAT

# Runner settings
PAT=<Your Personal access token>
RUNNER_URL=<runner url>
RUNNERS=1
# Vagrant image settings
MEMORY=8000 # 8GB
CPU=4
DISK_SIZE=100

Example with TOKEN

# Runner settings
TOKEN=<Your short lived acess token>
RUNNER_URL=<runner url>
RUNNERS=1
# Vagrant image settings
MEMORY=8000 # 8GB
CPU=4
DISK_SIZE=100

2) Create docker-compose.yml

version: "3.9"

services:
  windows-github-runner-vm:
    image: docker.io/vaggeliskls/windows-github-custom-runner:latest
    env_file: .env
    stdin_open: true
    tty: true
    privileged: true
    ports:
      - 3389:3389

3) Run: docker-compose up -d

🌐 Access via Remote Desktop

For debugging purposes or testing you can always connect to the VM with remote desktop softwares.

Some software that used when developed was

Linux: rdesktop rdesktop <ip>:3389 or remina
MacOS: Windows remote desktop
Windows: buildin Remote Windows Connection

🔑 User Login

The default users based on vagrant image are

1) Administrator

Username: Administrator
Password: vagrant

2) User

Username: vagrant
Password: vagrant

📚 Further Reading and Resources

Windows VM Inside a Linux Docker Container

vaggeliskls — Sat, 21 Oct 2023 13:05:27 +0000

When it comes to creating reproducible and isolated development environments, two leading technologies reign: Docker and Vagrant. Docker facilitates containerization by bundling applications and dependencies together, making the applications platform-independent. On the other hand, Vagrant is a tool for virtual environments, allowing the creation and management of virtual machines (VMs). Running a Vagrant VM, particularly a Windows VM, inside a Docker container creates a unique combination that can offer remarkable benefits, especially in the field of Continuous Integration (CI) and Continuous Deployment (CD). 🔂 🚀

Today, we'll tap into an existing GitHub repository that demonstrates how to implement a Windows VM within this Docker/Vagrant setup. The repository can be found at the following URL: https://github.com/vaggeliskls/windows-in-docker-container

Prerequisites 📑

Before proceeding, the following tools should be installed on your system:

How to Use It 🛠️

Create an environmental file .env with VMs specifications

# Vagrant image settings
MEMORY=8000 # 8GB
CPU=4
DISK_SIZE=100

Create a docker-compose.yml file

version: "3.9"

services:
  win10:
    image: docker.io/vaggeliskls/windows-in-docker-container:latest
    env_file: .env
    stdin_open: true
    tty: true
    privileged: true
    cgroup: host
    restart: always
    ports:
      - 3389:3389
      - 2222:2222

Run: docker-compose up -d

Remote Desktop 🖥️

For debugging purposes or testing, you can always connect to the VM with remote desktop software products. Some software that used when developed was:

Linux: rdesktop IP:3389 or remina
macOS: Windows remote desktop
Windows: build in Remote Windows Connection

User login 👤

The default users based on vagrant image are

Administrator
- Username: Administrator
- Password: vagrant
User
- Username: vagrant
- Password: vagrant

Conclusion 👋

Running a Vagrant Windows VM inside a Docker container merges the benefits of Docker's platform-independent containerization with Vagrant's controlled, easy-to-manage development environments. Although such a setup won't fulfill every use case, understanding how Docker and Vagrant operate and interact is highly beneficial for DevOps professionals.

Remember, different configurations exist and this setup can be tweaked to suit specific application requirements. Be aware that running a VM inside a Docker container can be resource-intensive, so always check your system's specifications before proceeding. 📝

Happy coding!

Forem: vaggeliskls

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

The Landscape: How Do You Want to Serve Files?

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

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

3. Sync-First Tools (Syncthing, Resilio)

4. WebDAV

Why I Built Two WebDAV Servers

Getting Started with webdav-server

Per-Folder Access Control

Authentication Options

What's New Since v1

Getting Started with cloud-webdav-server

Kubernetes Deployment with OCI Helm Charts

Practical Use Cases

Choosing the Right Approach

Links

Deploy a Secure Containerised WebDAV Server with Docker in Minutes

📖 What is WebDAV?

📦 Prerequisites

🚀 Key Features

🔧 Authentication Setup

🔐 Basic Authentication

🔐 OAuth Authentication

🔐 LDAP Authentication

📑 WebDAV Methods and Access Control

⚡ Usage Example

📚 References

Rehosting Bitnami Secure Images with Specific Tags

🔍 The Problem

🎯 The Goal

💡 The Solution

🚀 How It Works

✅ Conclusion – My Point of View

Buttercup Password Manager for Startups 🛡️

🌐 Why Choose a WebDAV Server?

🔑 Key Features

📥 Download the Buttercup Client

🚀 Getting Started

🔒 Secure Your Connection

🎉 Conclusion

Pull images from private docker registry in Kubernetes cluster 🐳

Supported Image Registries 🌐

Prerequisites 🛠️

Using the Helm Chart 🚀

Configuration

Examples

AWS ECR

Docker Based Registries Examples

Conclusion

Windows GitHub Self Hosted Runner inside a Linux Container

📋 Prerequisites

🚥 Authentication Methods for Self-Hosted

🚀 Deployment Guide

🌐 Access via Remote Desktop

🔑 User Login

📚 Further Reading and Resources

Windows VM Inside a Linux Docker Container

Prerequisites 📑

How to Use It 🛠️

Remote Desktop 🖥️

User login 👤

Conclusion 👋

References 📚