Devlog #4: Layered Config, HTTP Range & Multi-Backend Foundations

Over the past couple of days, I’ve been working on one of the biggest refactors since Minamo entered its MVP stage.

This update introduces a layered configuration system, HTTP Range support for S3-compatible downloads, a redesigned CLI, and a cleaner runtime state architecture.

To keep the project moving forward, I ended up working on Minamo almost everywhere I could — on my desktop, in GitHub Codespaces, through remote SSH sessions on a Linux server, and even from GitHub Mobile whenever I had a few spare minutes.

Unfortunately, development time spent through remote SSH sessions and GitHub Mobile isn’t tracked by Hackatime, so those hours don’t appear in my statistics.

Also, because this refactor involved lots of experimentation and incremental changes, I squashed many small commits into a single clean commit before pushing. The history is much cleaner now, even though it hides quite a bit of the work that went into this update.

Highlights

Layered Configuration System

The previous environment-variable-only configuration has been replaced with a layered configuration system:

CLI arguments
    ↓
Environment variables
    ↓
TOML configuration files

This makes deployments much more flexible while still allowing temporary overrides from the command line.

The refactor also introduces:

• ConfigManager
• Automatic configuration scaffolding
• config.example/ templates

HTTP Range Support

Minamo now supports HTTP Range requests for S3-compatible downloads.

Clients such as rclone and the AWS CLI can now download only the required portions of large objects instead of fetching entire files.

Supported formats include:

• bytes=start-end
• bytes=start-
• bytes=-suffix

The implementation correctly returns 206 Partial Content, Content-Range, Accept-Ranges, and proper 416 Range Not Satisfiable responses.

CLI & Runtime State

The CLI has been redesigned around subcommands:

• minamo init
• minamo run

Runtime-generated state has also been separated from user configuration, making deployments cleaner and preparing the project for future storage backends.

What’s Next?

The next milestone is adding additional storage backends.

Current roadmap:

Layered Storage Scheduling

Alongside new storage backends, I’m also redesigning Minamo’s storage scheduling architecture.

The long-term goal is to support a layered storage model, where frequently accessed (“hot”) data stays on fast local storage while less frequently accessed (“cold”) data can be transparently moved to lower-cost backends such as OneDrive.

Since Minamo hasn’t seen production workloads yet, this design is still largely based on theoretical considerations rather than operational experience. I fully expect it to evolve as the project matures and real-world usage reveals better trade-offs.

Cloudflare R2

This will likely be the first backend after the local filesystem.

Cloudflare R2 is surprisingly developer-friendly: it only requires a credit card for verification, includes 10 GB of free storage, and charges no egress fees. For many personal and small projects, I think it’s one of the best object storage services available.

Microsoft OneDrive

After R2, I plan to implement a OneDrive backend.

I wouldn’t recommend using a personal OneDrive account as production object storage. It isn’t designed for that, can be less reliable, and is relatively easy to hit rate limits (HTTP 429).

However, for personal projects or storing infrequently accessed “cold” data, it’s an incredibly cost-effective option and fits Minamo’s planned hot/cold storage architecture quite well.

Commit