Cómo un correo de renovación de $3,000 MXN nos hizo replantearnos por qué seguíamos pagando por un FTP externo. Te explicamos cómo migramos a sFTPGo en nuestro propio servidor con Coolify, cómo resolvimos el problema de no tener IP pública usando Tailscale, y cómo construimos un sistema de alertas en Discord que hoy nos da visibilidad total sobre cada carga de datos en tiempo real — desde el inicio del proceso hasta el detalle exacto de cada error.
Miguel Fernandez
Autor
En fencode teníamos un dominio que venía de una etapa anterior de la empresa. Ya no lo usábamos para nada visible, pero tampoco queríamos desperdiciarlo, así que le encontramos utilidad: lo configuramos como servidor FTP en Hostinger para transferir archivos CSV entre sistemas.
Funcionó. El primer año nos costo $1,000 MXN como ya no usabamos este dominio quizimos aprovechar el servicio de FTP. Era facil de usar, ya estaba configurado y no teníamos que pensar en ello.
Entonces llegó el correo de renovación: $3,000 MXN.
Por un FTP. Que solo usábamos para mover archivos. En un dominio que ni siquiera era nuestro nombre actual.
La respuesta fue unánime en el equipo: ni madres.
Antes de entrar a la solución, vale la pena explicar para qué usamos el FTP, porque el contexto hace que todo tenga más sentido.
En fencode manejamos cargas masivas de datos para nuestras aplicaciones saleshow.app y fernandezmarket.com. Hablamos de archivos CSV con alrededor de 3 millones de filas cada uno, que se procesan en días y horarios específicos de la semana.
El flujo funciona así:
El FTP es el puente entre el origen de los datos y nuestros procesos internos. Sin él, el flujo no funciona. Y pagar $3,000 MXN al año por ese puente, cuando ya teníamos nuestro propio servidor corriendo, simplemente no tenía sentido.
sFTPGo es un servidor FTP/SFTP moderno, open source y con panel de administración web incluido. A diferencia de soluciones más antiguas y complicadas de configurar, sFTPGo está pensado para correr en contenedores Docker, lo que lo hace perfecto para desplegarlo con Coolify en minutos.
Lo que más nos convenció:
Y lo más importante: costo adicional cero, porque ya teníamos el servidor.
Como ya teníamos Coolify corriendo en nuestro servidor, desplegarlo fue sorprendentemente sencillo. No tuvimos que instalar nada manualmente ni tocar configuración a mano: desde el panel de Coolify buscamos sFTPGo en el catálogo de servicios, lo desplegamos como un nuevo servicio, configuramos el puerto y el volumen donde se iban a almacenar los archivos, y en minutos ya teníamos el panel de administración accesible.
Desde el panel de sFTPGo creamos los usuarios con sus credenciales y definimos las carpetas a las que tienen acceso. Eso fue todo. Nuestro propio servidor SFTP corriendo, sin depender de ningún proveedor externo y sin costo adicional porque el servidor ya estaba ahí.
Vale mencionar que nuestro servidor corre Ubuntu Server con un procesador AMD Ryzen 7, 32 GB de RAM y almacenamiento NVMe, lo que nos da capacidad de sobra para manejar archivos CSV de millones de filas sin ningún problema de rendimiento.
Había un detalle adicional que resolver: nuestro proveedor de internet no nos asigna una IP pública, lo que significa que el servidor del cliente encargado de generar y depositar los CSV no podía conectarse directamente a nuestro sFTPGo por internet. La solución fue Tailscale, una herramienta que crea una red privada virtual entre dispositivos de forma muy sencilla. Instalamos Tailscale tanto en nuestro servidor como en el servidor del cliente, y listo: ambos quedaron conectados en una red privada segura sin necesidad de IP pública ni configuraciones complicadas de firewall. El cliente deposita sus archivos en nuestro sFTPGo como si estuvieran en la misma red local, aunque estén en ubicaciones completamente distintas.
Una vez que sFTPGo estuvo en marcha, integrarlo al flujo existente fue directo. Nuestros uploaders en Python ya estaban escritos, solo había que apuntarlos a la nueva dirección del servidor SFTP en lugar del antiguo FTP de Hostinger.
El flujo actualizado quedó así:
Base de datos externa
↓
Genera CSV automáticamente
↓
Deposita en sFTPGo (nuestro servidor)
↓
Uploaders Python toman los archivos
↓
Procesan y suben a bases de datos de producción
↓
Webhook notifica resultado en Discord
Limpio, sin intermediarios y sin costos adicionales.
Aquí es donde el proyecto se volvió algo de lo que estamos genuinamente orgullosos. No nos conformamos con solo mover el FTP, aprovechamos la migración para construir un sistema de notificaciones completo usando webhooks de Discord.
¿Por qué Discord y no correo o Slack? Porque ya lo usamos internamente, es gratis, y el código embebido de Discord para notificaciones permite mostrar información estructurada de manera muy legible.
El sistema notifica en tres momentos clave:
Cuando el uploader arranca, manda una notificación inmediata al canal de Discord indicando que el proceso comenzó. Esto es más útil de lo que parece: si no llega una notificación de éxito o error después, sabemos que el proceso fue terminado externamente por algo fuera de nuestro control.
Antes de procesar cualquier archivo, el uploader verifica que puede conectarse correctamente a sFTPGo y lo notifica. Si esta prueba falla, el proceso se detiene ahí y el equipo lo sabe de inmediato, sin tener que esperar a que todo el proceso falle al final.
Al terminar, Discord recibe un resumen completo que incluye cuántos archivos se procesaron, cuántos fueron exitosos y cuántos fallaron, el total de registros insertados, el tiempo total del proceso y el desglose por archivo. Por ejemplo, una carga típica puede verse así: 5 archivos procesados, 0 fallidos, más de 2.4 millones de registros insertados en poco más de 16 minutos.
Aquí es donde el sistema brilla de verdad. Si algo sale mal, Discord recibe una alerta con @everyone que incluye el tipo de error exacto, el mensaje completo, el contexto de en qué función falló y una acción requerida sugerida. Nadie en el equipo puede decir que no se enteró de que algo falló.
Tener ese nivel de detalle en los errores hace que resolver problemas sea infinitamente más rápido. En lugar de revisar logs en el servidor, el diagnóstico llega directo a Discord.
$3,000 MXN al año, exactamente. El servidor ya corría con Coolify, sFTPGo es open source y Discord es gratuito. El único costo fue de unas 5 horas de planeación e implementación.
Cuando llegó el correo de renovación de Hostinger, la reacción fácil hubiera sido pagar y seguir. Son $3,000 MXN, no es el fin del mundo. Pero en fencode antes de pagar por algo siempre nos hacemos la misma pregunta: ¿ya tenemos las herramientas para resolver esto nosotros mismos?
En este caso la respuesta era obvia. Teníamos un servidor propio corriendo con Coolify, sFTPGo existe y es open source, y el flujo que necesitábamos era exactamente para lo que fue diseñado. No tenía ningún sentido seguir pagando a un tercero por algo que podíamos hostear en nuestro servidor.
El resultado fue mejor de lo esperado: no solo dejamos de pagar $3,000 MXN al año, sino que terminamos con una solución más robusta, con visibilidad total del proceso gracias a Discord y con control completo sobre nuestra infraestructura.
Ese es nuestro enfoque en cada proyecto: antes de asumir que algo tiene un costo, evaluamos si existe una solución eficiente que ya esté al alcance. Muchas veces la hay, y la diferencia entre pagarla o construirla es simplemente saber dónde buscar.
En fencode diseñamos e implementamos flujos de datos, servidores self-hosted y sistemas de automatización a medida. Si tienes un proceso crítico que quieres optimizar o un gasto en infraestructura que no tiene sentido seguir pagando, podemos ayudarte a encontrar una mejor solución.
👉 Conócenos en fencode.dev y platiquemos.
Resolvemos las dudas específicas sobre este tema.
