DEV Community

Carlos Arturo Castaño G.
Carlos Arturo Castaño G.

Posted on

Cómo desarrollo sin cargar mi instancia EC2 (ni mi tarjeta de crédito en tokens)

#aws #opensource #productivity #selfhosted

Hay una narrativa dominante en desarrollo asistido por IA: entre más pagas, mejor herramienta tienes. Más tokens, más suscripciones, más servicios comerciales conectados. Yo fui por el camino contrario: lo simple, lo local, lo gratuito donde se pudo — y terminé con un flujo de trabajo más robusto, no menos.

Esto es lo que uso y por qué.

El problema que estaba resolviendo

Trabajo con un stack deliberadamente simple: Java 21, JavaScript ES6 vainilla, MongoDB, Nginx, todo sobre EC2. Nada de frameworks pesados, nada de servicios comerciales de pago recurrente si puedo evitarlo.

Pero tenía dos fricciones reales:

  1. Cargar la instancia EC2 con trabajo de desarrollo (editores, herramientas de análisis, IA corriendo localmente en el servidor) consume CPU y memoria que debería estar sirviendo producción, no editando código.
  2. Colaborar con alguien en otro sistema operativo (yo en Rocky Linux, mi colaborador en Windows) sin duplicar configuración ni depender de que ambos paguemos las mismas herramientas comerciales.

La solución: virtualizar la instancia, no cargarla

Uso rclone para crear una virtualización de la instancia EC2 en nuestros propios computadores locales. En la práctica:

  • La instancia EC2 sigue corriendo solo lo que debe correr en producción: la app, la DB, Nginx.
  • Yo, desde mi Rocky Linux, y mi colaborador, desde su Windows, montamos/sincronizamos esa instancia como si fuera parte de nuestro sistema local.
  • Todo el trabajo de desarrollo — edición, análisis, ejecución de agentes IA — corre con recursos de nuestros propios computadores, no de la instancia.
  • Podemos usar ambientes gráficos completos (editores, herramientas de análisis) como si estuviéramos trabajando directamente en el servidor, sin las limitaciones de una terminal SSH pelada.

El resultado: la instancia no se satura, nosotros trabajamos con toda la comodidad de un entorno gráfico local, y cada quien usa su propio sistema operativo sin fricción.
Usamos Opencode , Hermes openDesign local

El script que uso para montar la instancia

Esto es lo que corro en mi Rocky Linux cada vez que necesito trabajar contra la instancia. Monta el home de ec2-user, el directorio de sitios web (/var/www) y Tomcat, cada uno en su propio punto de montaje local, usando rclone mount con caché VFS en modo writes:

#!/bin/bash
# Script para montar directorios de EC2

# Colores para output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color

echo -e "${BLUE}════════════════════════════════════════════════════════════${NC}"
echo -e "${GREEN}          🚀 MONTANDO SERVICIOS EC2 - LINUX${NC}"
echo -e "${BLUE}════════════════════════════════════════════════════════════${NC}"
echo ""

sudo pkill -9 rclone
sudo umount -l /root/ec2-www
sudo rm -rf /root/ec2-www

MOUNT_POINT="/root/ec2-www"
CACHE_DIR="/root/.cache/rclone"

if ! mountpoint -q "$MOUNT_POINT"; then
    echo "Mount no activo, limpiando caché..."
    rm -rf "$CACHE_DIR/vfs/miproyecto"
    rm -rf "$CACHE_DIR/vfsMeta/miproyecto"
    echo "Caché limpiada. Remontando..."
fi

# Configuración del remote
REMOTE_NAME="miproyecto"

# Rutas remotas
REMOTE_HOME="/home/ec2-user"
REMOTE_WWW="/var/www"
REMOTE_TOMCAT="/usr/local/tomcatapp"  # Ajustar según tu instalación

# Rutas locales (puntos de montaje)
LOCAL_HOME="$HOME/ec2"
LOCAL_WWW="$HOME/ec2-www"
LOCAL_TOMCAT="$HOME/ec2-tomcat"

# Crear directorios locales si no existen
echo -e "${YELLOW}📁 Creando directorios locales...${NC}"
mkdir -p "$LOCAL_HOME" "$LOCAL_WWW" "$LOCAL_TOMCAT"

# Limpiar montajes previos
echo -e "${YELLOW}🧹 Limpiando montajes anteriores...${NC}"
fusermount3 -u "$LOCAL_HOME" 2>/dev/null
fusermount3 -u "$LOCAL_WWW" 2>/dev/null
fusermount3 -u "$LOCAL_TOMCAT" 2>/dev/null
pkill -f "rclone mount" 2>/dev/null
sleep 2

# Función para montar con verificación
mount_dir() {
    local name=$1
    local remote_path=$2
    local local_path=$3
    echo -e "${YELLOW}📂 Montando $name...${NC}"
    if rclone mount "$REMOTE_NAME:$remote_path" "$local_path" \
        --daemon \
        --vfs-cache-mode writes \
        --vfs-cache-max-age 10s \
        --daemon-wait 5; then
        sleep 2
        if mountpoint -q "$local_path"; then
            echo -e "${GREEN}✓ $name montado correctamente${NC}"
            return 0
        else
            echo -e "${RED}✗ $name: punto de montaje no verificado${NC}"
            return 1
        fi
    else
        echo -e "${RED}✗ $name: fallo al montar${NC}"
        return 1
    fi
}

# Montar cada directorio
echo ""
mount_dir "Home de ec2-user" "$REMOTE_HOME" "$LOCAL_HOME"
sleep 1
mount_dir "Sitios web (/var/www)" "$REMOTE_WWW" "$LOCAL_WWW"
sleep 1
mount_dir "Tomcat (/usr/local/tomcatapp)" "$REMOTE_TOMCAT" "$LOCAL_TOMCAT"
sleep 1

# Resumen final
echo ""
echo -e "${BLUE}════════════════════════════════════════════════════════════${NC}"
echo -e "${GREEN}✅ MONTAJE COMPLETADO EXITOSAMENTE${NC}"
echo -e "${BLUE}════════════════════════════════════════════════════════════${NC}"
echo ""
echo -e "${YELLOW}📍 Puntos de montaje:${NC}"
echo -e "   📁 ${GREEN}$LOCAL_HOME${NC}     → ${BLUE}/home/ec2-user${NC}"
echo -e "   📁 ${GREEN}$LOCAL_WWW${NC}      → ${BLUE}/var/www${NC}"
echo -e "   📁 ${GREEN}$LOCAL_TOMCAT${NC}   → ${BLUE}/usr/local/tomcatapp${NC}"
echo ""
echo -e "${YELLOW}💡 Comandos útiles:${NC}"
echo -e "   cd $LOCAL_HOME        - Ir al home remoto"
echo -e "   cd $LOCAL_WWW         - Ir a los sitios web"
echo -e "   cd $LOCAL_TOMCAT      - Ir a Tomcat"
echo -e "   tail -f $LOCAL_TOMCAT/logs/catalina.out  - Ver logs"
echo ""
echo -e "${BLUE}════════════════════════════════════════════════════════════${NC}"
Enter fullscreen mode Exit fullscreen mode

Puntos clave del script si quieres adaptarlo a tu propio setup:

  • REMOTE_NAME es el nombre del remote que configuraste previamente con rclone config (SFTP contra tu instancia EC2).
  • --vfs-cache-mode writes cachea localmente los archivos que modificas, evitando escrituras constantes sobre la red.
  • --vfs-cache-max-age 10s expira la caché rápido, así siempre ves el estado casi real del servidor sin acumular archivos viejos en disco.
  • El script limpia montajes previos con fusermount3 -u antes de reintentar, así evitas el clásico "transport endpoint is not connected" cuando la sesión SSH se cae.
  • Cada punto de montaje se verifica con mountpoint -q antes de darlo por exitoso — si rclone mount falla silenciosamente, te enteras al momento y no cinco minutos después cuando el editor no encuentra los archivos.

El resto del stack, igual de deliberado

  • opencode: mi navaja suiza. Es un fork gratuito de Claude Code, y lo combino con tmux como mi emulador de consola gráfica. Con esto tengo asistencia de IA para programar sin depender de una suscripción comercial cerrada.
  • Hermes: mi agente propio (WhatsApp + Gmail + MongoDB vía MCP), corriendo local, no en la nube de un tercero.
  • Frontend vainilla: JS ES6 sin build step, HTML5, Bootstrap, FontAwesome. Cero dependencia de un pipeline de compilación que además consume recursos.
  • Escalado bajo demanda: la instancia EC2 solo crece cuando el negocio lo requiere de verdad, no porque el proceso de desarrollo la esté exigiendo.

Por qué esto importa si trabajas con presupuesto ajustado

La narrativa de "necesitas pagar más tokens / más suscripciones / más servicios para ser productivo" no es cierta si diseñas tu flujo con intención:

  1. Separa desarrollo de producción físicamente. Si tu servidor de producción también es tu entorno de desarrollo, cada herramienta que instalas ahí compite por los mismos recursos que sirven a tus usuarios reales.
  2. rclone (u otra herramienta de sincronización/montaje similar) te permite trabajar "como si estuvieras en el servidor" sin estar en el servidor. Es la diferencia entre depender de la instancia y usarla solo para lo que debe hacer.
  3. Herramientas de IA locales o gratuitas (opencode, modelos vía OpenRouter, agentes propios) reducen la dependencia de gasto recurrente en tokens sin sacrificar productividad, si las combinas bien.
  4. Colaboración multiplataforma no requiere que todos usen el mismo sistema operativo ni las mismas licencias, si el punto de sincronización es la data, no el entorno.

Conclusión

No hace falta perseguir cada herramienta nueva del mercado ni escalar recursos en la nube para "sentirse productivo". A veces la mejora real viene de una decisión de arquitectura simple: dónde corre cada cosa y por qué. Mi instancia EC2 sirve producción. Mi laptop hace el trabajo pesado de desarrollo. Y mi bolsillo lo agradece.

¿Alguien más está resolviendo colaboración multiplataforma con rclone u otra herramienta similar? Me interesa comparar setups.

Top comments (0)