Publicar sin Git: del ZIP al sitio en línea en minutos

Tecnologías compatibles sin Dockerfile

Si hay un Dockerfile en la raíz del ZIP, se usa en lugar de la receta automática. Si no lo hay, el log del build muestra el Dockerfile generado, útil para entender y corregir un error.

Paso a paso

• Crea tu cuenta en devoracloud.com/register (7 días gratis, sin tarjeta).
• En el panel, crea un proyecto nuevo y elige la subida por ZIP.
• Sube el archivo (hasta 512 MB).
• Sigue el build: análisis, construcción, publicación y verificación de salud.
• Cuando el estado esté listo, el sitio responde en https://tu-proyecto.apps.devoracloud.com con certificado automático.

¿Prefieres no hacer nada de esto? Genera el token de IA en el panel y pídele a tu IA que publique: prepara el ZIP, crea el proyecto y sigue el build por ti.

Cómo armar el ZIP

Pon en la raíz del ZIP el archivo que identifica el proyecto: package.json, requirements.txt, go.mod o index.html. Una única carpeta en el nivel superior también funciona. Usa ZIP; el formato tar no se acepta.

Deja fuera:

• node_modules: las dependencias se instalan en el build.
• .next, dist y build: el build se rehace en la plataforma.
• .git: el historial no hace falta.
• .env y cualquier archivo con contraseñas o claves: usa las variables de entorno del proyecto.
• Subidas de usuarios y bases locales, como archivos .sqlite: los archivos van a S3 y los datos a PostgreSQL.

Un ZIP ligero sube más rápido y evita llevar a la nube cosas que solo tenían sentido en tu ordenador.

PORT y 0.0.0.0: el error más común

La aplicación debe escuchar en la dirección 0.0.0.0 y en el puerto que indica la variable de entorno PORT. Si escucha solo en localhost (127.0.0.1) o en otro puerto fijo, el build termina bien, pero la verificación de salud no llega a la app y el despliegue falla.

• Node.js: app.listen(process.env.PORT || 3000, "0.0.0.0").
• Next.js: el script start por defecto (next start) ya respeta PORT.
• Python: arranca el servidor (uvicorn, gunicorn) con host 0.0.0.0 y el puerto de PORT.
• Go: lee os.Getenv("PORT") y escucha en ":" + puerto.

Revisa también los scripts: en proyectos Node, el package.json necesita build (si hay etapa de build) y start.

Otros errores comunes en el primer despliegue

Si el despliegue falla, abre el log antes de cambiar nada. Los casos más frecuentes se resuelven fácil:

• Dependencia que falta: el paquete funciona en tu ordenador porque lo instalaste a mano, pero no está en package.json ni en requirements.txt.
• Versión de runtime incorrecta: el proyecto necesita otra versión de Node.js o Python distinta de la que detectó el build.
• Mayúsculas y minúsculas en los nombres de archivo: funciona en Windows o macOS, pero no en el Linux del build.
• Variable de entorno ausente en el build: el código lee una clave que solo existía en tu .env local.

Corrígelo, genera un ZIP nuevo y vuelve a publicar. Mientras tanto, la versión anterior sigue en línea.

Variables, base de datos y S3

Las contraseñas y claves se configuran como variables de entorno del proyecto, disponibles en el build y en la ejecución. Si el sistema usa base de datos, crea PostgreSQL o Redis antes del primer despliegue: la conexión llega a la app como DATABASE_URL (o REDIS_URL). Para imágenes y documentos, crea el S3 privado del proyecto; la app recibe las variables S3_* listas.

Nunca pongas secretos en variables que lee el navegador, como las que empiezan por NEXT_PUBLIC_.

Nuevas versiones y GitHub más adelante

Para actualizar, sube un ZIP nuevo y vuelve a publicar. Un despliegue fallido nunca sustituye la versión en línea: el sitio sigue funcionando mientras corriges.

Cuando el proyecto madure, conecta GitHub una vez en el panel, en Conexiones, y vincula el repositorio al proyecto. Desde entonces, cada push a la rama elegida genera un despliegue. La subida por ZIP sigue disponible si la prefieres.

Preguntas frecuentes