Reserved.

How I can add more volumes to Minio? I tryed to duplicate, but console doesnt see new volume.

At this time Railway doesn't support adding more than one volume to a service.

Is the default MINIO_ROOT_PASSWORD of the template secure and ready for production?

Nvm I found out how to change it after deployment.

It is absolutely secure and ready for production.

It is randomly generated 48 characters long.

No two template deployments will have the same password.

I'd recommend not changing variables as we can not help with password recovery.

Hi, just deployed this.
Deployment and setup was smooth, and console works well. However something must be miss-configured, as Signed URLs does not work.

An easy way to test this is using the Bun 1.2 S3 client.

import { S3Client } from "bun";

const s3 = new S3Client({
  endpoint: "https://....up.railway.app/",
  accessKeyId: "...",
  secretAccessKey: "...",
});

await s3.file("bucket/test.txt").write("test");

This gives a SignatureDoesNotMatch error. Same access key and secret works in the console.

I then deployed the bitnami/minio:2024 image separately and for that one the signed URLs work well. I could point the console deployment from the template to this container as well to get the UI working.

Hmmmm, I wonder what the bitnami image is doing differently, I'm all ears if you have any ideas?

For those that encounter failed deployments and various issues I had to change the following after adding the template:

1. Delete the "Console" Service: the MinIO server now includes the web console apparently. So you do not need a separate "console" service.

2. Update ENV vars:

```

MINIO_ROOT_PASSWORD="your-root-password-here"

MINIO_ROOT_USER="your-root-username-here"

MINIO_API_PORT="9000"

MINIO_CONSOLE_PORT="9001"

MINIO_DATA_DIR="/srv/minio/data"

PORT="9001"
```

3. Update the Healthcheck Path: Change the value from /minio/health/ready to just /.

4. Edit Public Networking port to 9000

Howdy!

I tried running this template without interacting with it at all, and I’m seeing that the used storage space in the attached volume is steadily growing, very slightly each day, and it doesn’t seem to stop.

Here is my project ID: fabcacce-40b6-4c73-aa22-f5a0d17e937a (it will be deleted eventually).

On launch day, the initial space used in the volume was 152 MB. Now, three days later, the used space is 308 MB. The growth looks linear, at about 50 MB per day.

I asked both ChatGPT and Claude, and they suggested this could be due to some metadata file creation. But that doesn’t really make sense to me. Why would the bucket storage service need to create metadata files in an empty bucket that hasn’t been interacted with?

Also, an increase of about 50 MB daily would mean that with a storage volume of 5 GB, it would be filled in just 100 days, without uploading any actual files.

I figure this might not be the best place to dig into this behavior, and maybe reaching out to the MinIO development community would be better. Still, I just wanted to check if anyone here knows what could be causing it before I do that.

Anyway, I hope someone here has some insight.

Cheers!

Alright, I am going to terminate the project above. I think I have enough data to demonstrate the issue. I want to emphesize that I never interacted with the bucket service or the console.

I'm also seeing some storage weirdness, but not quite as back as bad as rpuls

I would speculate its some kind of runaway health/log process?

I have tried to dig a little deeper, using SSH to inspect the volume, but whe file system does not show any files of significant size, this is what I saw:
```
C:\Users\Rasmus>railway ssh
✓ Connected to interactive shell
bash-5.1# du -sh /data/* | sort -rh
16K /data/lost+found
bash-5.1# du -sh /data/* /data/.[!.]*
16K /data/lost+found
116K /data/.minio.sys
bash-5.1# du -sh /data/.minio.sys/*
20K /data/.minio.sys/buckets
32K /data/.minio.sys/config
4.0K /data/.minio.sys/format.json
4.0K /data/.minio.sys/multipart
8.0K /data/.minio.sys/pool.bin
60K /data/.minio.sys/tmp
bash-5.1# du -sh /data/.minio.sys/**/*
16K /data/.minio.sys/config/config.json
12K /data/.minio.sys/config/iam
4.0K /data/.minio.sys/pool.bin/xl.meta
4.0K /data/.minio.sys/tmp/ff55f63e-1f29-4a88-b27b-62c40fc51f08
bash-5.1# du -sh /data/.minio.sys/multipart
4.0K /data/.minio.sys/multipart
```

Yet the railway metrics chart shows volume start at 71MB and then keeps increasing in size as described above.

I was considering reaching out to MinIO on their slack, but since I can see no file of any size, I a not sure what to ask them. Could this be a bug in Railways metrics? @brody

You would want to reach out to MinIO on slack, there's no bug with the volume metrics given this volume usage increase has only ever been reported by you running MinIO.

I'm not the only one experiencing this though, I am co-reporting it for someone else who gave me the exact reproduction steps, and I have done 3 tests now, it's 100% consistent behavior. Will try to see if I can reproduce it in a local docker container, if that checks out I have reproduction steps for the MinIO team.

I have also experienced the same problem and decided to shutdown the instance.

I tried to investigate this. But I was never able to recreate the same behavior on my local environment.

I have had this one running for a few months, just to monitor it, and it cycles like this; once it hit around 2 GB it it start reducing to around 1 GB, and then the it starts slow linear increase again. I have never uploaded any files to this instance for the record, it just does this passively.

I also inspected it with SSH, and there are no large files to be seen.