Tu propio S3: por que deje de guardar archivos en el disco del contenedor

El día que reconstruí la imagen de una aplicación y desaparecieron los comprobantes que habían subido los clientes, entendí el problema de fondo: un contenedor es desechable y un archivo no.

La primera reacción es montar un volumen y seguir. Funciona, y durante un año fue lo que hice. Lo que se rompe después es todo lo demás.

Qué se rompe con un volumen

Un volumen te resuelve la permanencia y nada más. Lo que sigue sin resolver:

• Dos contenedores no comparten bien un disco. Mi aplicación corre en app, queue y scheduler. Si el trabajador en cola genera un PDF, tiene que estar en el mismo volumen que la web, y ahora esos tres contenedores están atados a la misma máquina para siempre.
• El respaldo es tuyo. Un volumen no tiene versiones, ni ciclo de vida, ni un aws s3 sync que lo copie a otro lado.
• Servir el archivo pasa por PHP. Cada descarga se lleva un proceso de php-fpm durante todo el tiempo que dure. Con archivos de 20 MB y tres personas descargando, se nota.
• El día que muevas la aplicación, hay que acordarse del volumen. Y de los permisos. Y del chown.

S3 no es "un disco en la nube". Es un protocolo que ya decidió esas cuatro cosas por ti.

Por qué propio y no Amazon

Monté MinIO en el mismo servidor, detrás de nginx y con su subdominio. Tres razones concretas:

El costo de salida. En Amazon el almacenamiento es barato y la transferencia de salida no. Una plataforma que sirve fotos de expedientes todo el día paga por cada descarga. En mi VPS la transferencia ya está incluida en lo que pago al mes.

Los datos no salen del país ni de la máquina. Cuando el contenido son credenciales de elector y expedientes clínicos, esa frase deja de ser ideología y se vuelve una respuesta que hay que dar por escrito.

Es el mismo código. MinIO habla el protocolo de S3, así que en Laravel el disco se configura igual que el de Amazon. Si mañana esto crece y hay que mudarse a Amazon de verdad, cambian tres variables de entorno y ninguna línea de código.

// config/filesystems.php - es el driver s3 de siempre
's3' => [
    'driver' => 's3',
    'endpoint' => env('AWS_ENDPOINT'),          // lo unico que cambia
    'use_path_style_endpoint' => true,          // y esto
],

Las dos cosas que me mordieron

use_path_style_endpoint no es opcional. Amazon direcciona los buckets por subdominio: mibucket.s3.amazonaws.com. Un MinIO propio no puede hacer eso sin un certificado comodín y un DNS que lo acompañe. Sin esa bandera en true, el SDK arma URLs que no resuelven y el error que ves no habla de DNS: habla de credenciales. Perdí una tarde ahí.

La consola no va a internet. MinIO trae dos puertos: la API de S3 y una consola web de administración. La API tiene que ser pública para que sirva archivos. La consola no tiene por qué serlo nunca. La mía solo escucha en loopback y llego a ella por un túnel SSH cuando necesito crear un bucket. Publicarla es regalar un panel donde se ven —y se borran— todos los archivos de todas las aplicaciones.

Y una advertencia sobre cómo se comprueba: un curl -I contra el endpoint de S3 devuelve 403, no 200. Es correcto: le estás pidiendo el listado raíz sin firmar la petición. Si lo monitoreas esperando un 200 vas a tener una alerta falsa cada minuto.

Cuándo no vale la pena

Tres casos donde le pagaría a Amazon sin pensarlo:

1. Cuando los archivos importan más que el servidor. Mi MinIO vive en la misma máquina que las aplicaciones. Si se pierde el disco, se pierde todo junto. Amazon replica en tres zonas; yo replico en un respaldo que tengo que acordarme de hacer.
2. Cuando hay que servir mucho a mucha gente. Un CDN de verdad delante de un bucket de verdad no lo empatas con un VPS.
3. Cuando nadie va a operar esto. MinIO es un servicio más que actualizar, respaldar y vigilar. Si el equipo no lo va a atender, un servicio administrado sale más barato aunque la factura diga lo contrario.

Para lo mío —archivos de trabajo, tráfico interno, datos que no deben salir— la cuenta sale a favor. Pero la sale porque ya tengo el servidor, ya tengo nginx al frente y ya tengo el hábito de respaldar. Si te falta alguna de las tres, el S3 propio no es un ahorro: es una tarea nueva.