Hardening Lioran S3 deployments with Caddy and Docker

Swaraj Puppalwar published a detailed deployment guide for Lioran S3 V1 Pre-Alpha on October 1, outlining a production-ready architecture that pairs the Rust-based storage engine with Caddy as a reverse proxy. The article serves as a critical reference for engineers evaluating this self-hosted, S3-compatible object store, highlighting specific configuration pitfalls and security hardening steps required before handling real data.

What happened

The guide describes a specific infrastructure pattern where Caddy handles public-facing HTTPS termination and certificate automation, while the Lioran S3 process, referred to as Bastion, operates on a private network over HTTP. This separation allows the storage engine to focus exclusively on data integrity and retrieval without managing TLS complexity. The recommended setup uses Docker Compose to orchestrate the containers, ensuring that the storage service remains isolated from direct internet exposure while still serving secure requests through the proxy.

Puppalwar emphasizes that this software is currently in a pre-alpha state, intended primarily for evaluation and testing rather than mission-critical production workloads. The article warns operators to rigorously validate failure behaviors and harden the host environment before storing any significant data. It provides a step-by-step walkthrough for cloning the repository, configuring environment variables, and launching the services, but stresses that successful container startup is only the beginning of a reliable deployment.

Key details

• Architecture: Caddy terminates HTTPS on port 443 and forwards traffic to Lioran S3 on a private HTTP port, typically 27118.
• Durability modes: Users must choose between strict mode, which ensures explicit synchronization boundaries for crash consistency, and balanced mode, which relies more on OS writeback behavior for higher throughput.
• Data persistence: Object data and metadata must be mounted to persistent storage volumes; using disposable container storage will result in data loss.
• Security configuration: Default admin credentials must be replaced, CORS origins should be restricted to specific domains, and a long random signing secret must be set to ensure URL stability across restarts.
• Disk management: The server includes low-watermark protection, but administrators must configure sufficient free-space headroom to prevent the host filesystem from filling up and crashing neighboring services.
• Observability: Health checks and metrics are available via HTTP endpoints and a dedicated CLI tool for monitoring system status and performance.

Background

Lioran S3 is an open-source, S3-compatible object storage server built in Rust by Lioran Developer Solutions. It uses RocksDB for metadata management and is designed to be lightweight and efficient. In modern self-hosted environments, object storage is often used for backing up application data, storing user uploads, or serving static assets. Unlike traditional file systems, object stores manage data as discrete units with unique identifiers, making them scalable and easier to distribute.

Using a reverse proxy like Caddy in front of such services is a standard practice in DevOps. Caddy automates the acquisition and renewal of TLS certificates from Let's Encrypt, removing the manual burden of certificate management. By offloading HTTPS termination to the proxy, the backend application can operate more simply and securely within a private network, reducing its attack surface and simplifying its codebase.

Why it matters

For teams running their own infrastructure, the distinction between strict and balanced durability modes is crucial. In a cloud environment, durability is often assumed, but in self-hosted setups, power failures or kernel panics can lead to data corruption if writes are not properly synchronized. Choosing strict mode sacrifices some write speed for guarantee that data is physically on disk before acknowledging the upload, which is vital for backup archives or legal records.

The emphasis on persistent storage mounts addresses a common error in Docker deployments. Containers are ephemeral by design, meaning any data written inside them disappears when the container is removed or recreated. Engineers must explicitly map host directories or volume drivers to the container’s data path. Failing to do so turns a storage server into a temporary cache, leading to catastrophic data loss during routine maintenance or updates.

Additionally, the guide highlights the importance of disk headroom. Storage servers can aggressively consume available space, potentially starving the operating system of resources needed for basic functions like logging or swapping. By configuring low-watermark protections and monitoring disk usage, administrators can prevent a single service from taking down the entire host, ensuring better overall system resilience.

What you can do

• Review the .env.production.example file carefully and replace all default values, especially admin passwords and signing secrets, before launching the stack.
• Set BASTION_DURABILITY=strict if data integrity is more important than raw write throughput, particularly for archival use cases.
• Verify that your Docker Compose file maps the BASTION_DATA_DIR to a persistent volume or host directory that survives container restarts.
• Configure Caddy to handle large request sizes and appropriate timeouts to support streaming large objects without buffering them entirely in memory.
• Restrict BASTION_CORS_ORIGINS to your specific application domains instead of using wildcards to prevent unauthorized browser-based access.
• Implement regular health checks using the provided endpoints or CLI tools to monitor latency and disk usage trends over time.