Devlog #1: Building Minamo

I’m excited to share the very first development update for Minamo.

Minamo is an S3-compatible storage gateway designed to reduce storage costs while remaining fully compatible with existing S3 clients. The long-term goal is to intelligently manage object placement, keeping frequently accessed data on fast storage while transparently moving cold data to lower-cost storage.

The project is currently about 50% complete.

Why Minamo?

The idea came from developing my AI chat application, Arona Chat.

While building its attachment system, I noticed that most uploaded files are accessed frequently for only the first few days before becoming “cold” data. They still need to be retained, but keeping everything on expensive hot storage unnecessarily increases operating costs.

That led to a simple question:

What if an S3-compatible gateway could automatically keep hot data on fast storage while moving cold data to lower-cost storage?

That’s how Minamo began.

Development Strategy

Rather than building the complete multi-tier storage system from the beginning, I’m developing Minamo in stages.

The first milestone is a Local Disk-only MVP, focusing on implementing a correct S3-compatible server before introducing additional storage providers.

To make future expansion straightforward, the project already adopts a layered architecture:

• HTTP / S3 API Layer (FastAPI) — request handling, XML responses, AWS Signature Version 4 verification
• S3 Service Layer — business logic and S3 error mapping
• Metadata Layer — provider-independent SQLite metadata
• Storage Backend Interface — pluggable abstraction with a Local Disk backend for the MVP

This separation allows future storage backends to be added with minimal changes.

Current Progress (~50%)

The MVP is actively under development.

Implemented so far:

• PutObject / GetObject / DeleteObject / HeadObject
• ListObjectsV2 (prefix, delimiter, pagination)
• Bucket operations
• Multipart Upload
• Presigned URLs
• AWS Signature Version 4 (header & query authentication)
• AWS-chunked streaming uploads

Compatibility is continuously verified against the official AWS SDK, with 22 boto3 compatibility tests currently passing against a live server.

The remaining work mainly focuses on completing the MVP and polishing compatibility before introducing additional storage providers.

Looking Ahead

Alongside finishing the Local Disk MVP, I’m designing Minamo’s future storage orchestration system.

The long-term vision is an intelligent storage gateway capable of automatically managing data across multiple storage tiers, including high-performance local storage, cache layers, and low-cost cold storage, while remaining fully compatible with the S3 API.

Hopefully Minamo can help make self-hosted object storage both more affordable and more efficient.

Thanks for reading! If you’re interested in the project, feel free to follow the project. I’ll share another devlog once the Local Disk MVP is complete and development moves into the multi-storage stage.

Changes

This update introduces benchmarking and metadata-related features, along with improvements to the trainer engine and documentation.

Detailed changes:

• Add benchmark.py for training performance evaluation
• Add test_benchmark.py and test_metadata_features.py to improve test coverage
• Enhance the trainer engine with advanced evaluation capabilities
• Improve LoRA method exporting with detailed example configurations
• Update documentation with comprehensive usage and configuration examples

Status

With this update completed, the training framework is now ready for official use.

For detailed usage instructions and examples, please refer to:

• Demo Guide: DEMO.md
• Usage Guide: USAGE.md

Minimum Hardware Requirements

Please note that this project has relatively high resource requirements. The following configuration is recommended as the minimum supported environment:

OS: Ubuntu 24.04 LTS
RAM: 64 GB
GPU VRAM: At least 12 GB
NVMe SSD (recommended for latent/text-encoder caching)

Running below these requirements may result in insufficient memory, significantly reduced performance, or inability to complete training.

Thank you for following the development of this project.

Commit

After fixing a number of issues, the Arona Chat Public Demo is finally ready!
You can try it using the link below.

https://aronachat.yearcakes.com/

Changes Made

Checkpoint System:

• Added thread-safe locking for checkpoint writes to prevent corruption
• Required optimizer_state_dict validation for checkpoint integrity
• Stopped background writers in test cleanups to prevent resource leaks
• Added cache_vae_dtype config field with fp32/bf16 tradeoff options

Dataset & Caching:

• Migrated dataset caching from pickle to safetensors format for faster/safer storage
• Added cache_vae_dtype VAE precision control (fp32 safe, bf16 faster/lower VRAM)
• Added seed parameter for reproducible dataset shuffling and deterministic sampling

Performance Optimizations:

• Added TF32 matmul and cuDNN benchmark for CUDA hardware
• Added torch.compile support for UNet with dynamic shapes
• Enabled pin_memory on CUDA for faster data transfer
• Added VRAM monitoring throughout training phases
• Reset peak memory stats per epoch for accurate telemetry

Hardware Guardrails:

• Added GPU-first guard verification test (skips on CUDA-enabled machines)
• Added mixed_precision=‘no’ VRAM usage warnings for <16GB GPUs
• Better handling of CPU RNG states after map_location=“cuda” loads
• GPU memory cleanup after model offloading

Testing:

• Fix test_checkpoint.py to shutdown background writers
• Add GPU-first guard test that requires non-CUDA environment

Commit

Upcoming Changes:

• Add more personalization features, such as customizable tone and emoji usage.
• Refine the Ethereal Light theme.

feat: add gradient accumulation and offload checkpoint writes to a background worker

• Accumulate gradients across micro-steps: zero grad only at window start, scale loss by acc_steps, and step optimizer/scheduler at window end.
• Move snapshot serialization to a background thread so disk I/O and the “latest” copy no longer stall training; recovery checkpoints stay synchronous for crash-durable resume.
• Clone state to CPU (_to_cpu) before enqueueing to avoid GPU OOM and in-place corruption by later training updates.
• Treat rolling recovery checkpoints as a minimal resume set (LoRA+RNG only); full snapshots still store optimizer/scheduler/scaler state. Resume from a rolling checkpoint rebuilds optimizer momentum and LR schedule from scratch.
• Make CaptionProcessor RNG thread-safe with a lock for concurrent prefetch.
• Add flush()/shutdown() for deterministic test state and clean process exit.

Commit

After fixing a number of issues, the Arona Chat Public Demo is finally ready!
You can try it using the link below.

https://aronachat.yearcakes.com/

AronaChat v1.2.0 — A Bigger Update Than The Version Number Suggests

Today, I completed AronaChat v1.2.0!
Although this is only a minor version bump, it actually includes a lot of major improvements and new features.
In this update, I added multi-provider support, custom models, the new Ethereal Light theme, and many other improvements. There are still many things to polish, but I’m working hard to turn AronaChat into something that we can genuinely use in our daily lives — not just a project.
The current codebase has grown into a very complex system, so I’m planning to deploy the Public Demo version tomorrow.
But this Public Demo is not just a temporary showcase. My goal is to make it a long-term usable product. You will be able to connect your own API providers and use AronaChat with your own services.
To protect your privacy and security, the current version includes encrypted API key storage and multiple layers of security protection to keep your credentials as safe as possible.
Due to storage and cost considerations, each user will have a fixed storage quota. If the limit is exceeded, attachments will be automatically removed using a FIFO (First In, First Out) rolling deletion system.
For chat history, I’ll try my best to keep conversations stored for as long as possible while maintaining reasonable operating costs.
Thank you for following the development of AronaChat!
This is still just the beginning, and I hope it can become a tool that people truly enjoy using.

Two small polish passes today!

• 📜 Quieter training logs — our console used to shout a full stats line every single step (so noisy 😵). Now it whispers just once every 1,000 steps. Don’t worry though — the little tqdm progress bar still wiggles along in real time, so you always know we’re alive and training! 🐣
• 🏷️ LoRA name tags — when we export a LoRA, we now tuck proper kohya-standard metadata into the safetensors header. That means sd-webui, ComfyUI, and friends finally recognize our SDXL LoRA and scale it correctly instead of squinting confused. We even peek at a lora_down weight to auto-detect the rank~ 🔍
  Small changes, cozy results!

Commit

The core development work is pretty much done! I’m now moving into the final polishing phase—doing security reviews, testing everything thoroughly, and fixing all the little rough edges I can find.
Once that’s finished, I’ll deploy the new build as a public instance that everyone can use long-term. Can’t wait to share it with you all!

🌸 Devlog Update
I’m currently exploring a better and more reasonable resource limitation system, hoping to make the DEMO experience smoother, friendlier, and more enjoyable for everyone!
I’m also working on adding support for custom model providers, so you’ll be able to add your own providers and use this project as a complete long-term solution instead of just a DEMO.
Of course, this also brings some new challenges qwq
Since users will be able to add their own API Keys, I need to carefully design a secure system to make sure your keys stay safe and never get exposed. I’m planning a layered architecture with encryption, multiple authentication layers, and additional security protections.
This project is becoming much more complicated than I originally expected… but I want to build it properly instead of rushing it 🥺✨
🌱 About Storage
S3-compatible storage is really expensive qwq, so for now I’ve added per-user file size limits and a 7-day automatic cleanup system.
I know these limits are a little too strict, and I’m really sorry about that 🥲💦
I hope you can understand that I’m still a solo developer trying to keep the service sustainable.
To improve this, I’m building my own tiered storage system — Minamo 🌊
After Minamo is finished, attachment storage limits will be increased significantly, and the 7-day automatic cleanup will be removed! 🎉
If you like this project, you can follow this project or follow Minamo to receive future updates and new features 💫
Thank you so much for supporting this project! 💙

Whitelist is almost finished! There’s only a little bit left to polish, and I should have it done within the next few days. New ship coming soon™

fixed a sneaky little bug: SDXL micro-conditioning was using the resized image size and crop coords, which was a bit off~ now it happily uses the TRUE original size and original-image-space crop offsets, matching the kohya / diffusers convention, so the model finally understands each image’s real backstory

also, caption augmentation used the global random, so it got all mixed up on resume (´；ω；`) gave it its own little seeded RNG baby — its state is saved with the checkpoint and restored exactly, so training picks up right where it left off, no getting lost.

collate got a tiny shield too: if a batch mixes cached/uncached samples, it now complains LOUDLY instead of throwing a cryptic KeyError

Commit

Hi~ today the trainer went on a little diet!

• The VAE and Text Encoders were freeloaders. Once everything is cached, they just sit on the GPU sunbathing and eating ~2GB of VRAM for no reason. So now we politely walk them over to the CPU couch before training starts, and only invite them back if we actually need them.
• xformers joins the party. The UNet now uses memory-efficient attention when it’s installed, and quietly falls back to plain SDPA if it isn’t — no drama, no crashes.
• The caching progress bar finally tells the truth. Before, it counted already-cached samples as “work” and lied about the ETA. Now we pre-scan everything first, so the bar only moves for real encoding. Honest bar is best bar.
  Result: less VRAM, faster start, happier GPU. Nap successful.

Commit

Gave precaching a little diet today! Added a VAE-slicing toggle (off by default = faster), and now we hand VRAM back to the GPU after every batch (no more sneaky CUDA hoarding~). Single-file checkpoints now only carry the UNet home instead of lugging the whole pipeline. Shoved caption augmentation into the prefetch thread, and the progress bar got smarter — it counts only real encodes, not the lazy “already-cached” ones. The GPU is having an easy day, meow~

Commit

Status Update!

• [IN PROGRESS] New frontend UI theme — Ethereal Light
  • [DONE] Draft
  • [DONE] Animations
  • [DONE] Visual polish
  • [DONE] Final UI review - almost done
• Whitelist
• User resource usage limits (for the demo)
• Lazy frontend loading

Two little wheels rolled into the trainer today:
🎯 Aspect-ratio bucketing: no more squishing every image into a square! Each pic now hops into the bucket whose ratio fits it best, gets a gentle cover-resize + center-crop, and BucketBatchSampler keeps same-bucket pals together so batches stack nice and tidy.
🏷️ Cute caption magic: Kohya-style tag shuffling, keep_tokens to pin the first few tags, and playful tag / whole-caption dropout — data augmentation now feels like sprinkling sugar 🍬.

Also fixed a sneaky SDXL detail: we now record each image’s real original_size and crop_ltrb and feed them into add_time_ids, instead of pretending everything is a 1024² square.
The cache grew up too — one combined cache_{hash}.pt carrying latents + text-encoder outputs + metadata, always saved to disk so reruns load in a blink, with shape checks that auto-recompute if you resize.
And the UNet now takes a nap 💤 until caching is done, freeing VRAM for the little GPUs that could.

Commit

✨ Precaching got a turbo boost! 🚀

Hi hi~ today the caching step stopped being such a lazy little snail! 🐌➡️🐇

• Before, we loaded one image, encoded it, saved it… one… by… one… zzz 😴 The GPU was basically napping while the disk did all the reading.

• Now we have a squad of worker threads (cache_workers) fetching images in parallel while the GPU chomps through them in batches (cache_batch_size). I/O and compute finally hold hands and work together! 🤝

• Bonus: a cute little progress log tells you img/s and ETA, so you know exactly when snack time ends. 🍪⏱️

• Also added a safety hug for resumes!
  If you try to resume a checkpoint with a different config, the trainer now gently stops and asks “are you suuure? type ‘yes’~” 🥺 No more silently mixing old weights with new settings and crying later. In non-interactive mode it just aborts to keep you safe. 💖

Commit