Hacés push, tu VPS se actualiza solo

Elegís el repositorio y la rama, y el panel clona el código en el VPS, crea el webhook en GitHub y deja todo listo. Desde ahí, cada push a esa rama dispara un pull, corre tus scripts de build y reinicio, y queda registrado qué commit se desplegó. Es el flujo de una plataforma tipo Vercel, sobre un servidor donde tenés root y el precio no depende de cuánto tráfico tengas.

  • Webhook creado solo
  • Scripts de build y reinicio
  • Historial de commits

Ver planes · Crear cuenta gratis

Así se ve en el panel

Capturas reales del panel de ArduMaker, no mockups.

Deploy desde GitHub: Deploy desde GitHub
Deploy desde GitHub. Rama, último sync y cada pull con sus pasos y duración.
Deploy desde GitHub: Scripts de build
Scripts de build. Lo que corre antes y después de cada pull, con plantillas.

Elegís el repositorio y queda publicado

En Apps el despliegue es un solo paso: elegís el repo y la plataforma hace el resto. Todo lo que arma queda a la vista en el VPS y lo podés cambiar.

  • Detecta el proyecto: Node.js, sitio estático (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) o un Dockerfile.
  • Antes de desplegar muestra cómo va a compilar, cómo va a servir y a dónde apunta nginx, con lo detectado ya escrito. Lo confirmás o lo cambiás.
  • Le da una dirección https automática; tu dominio lo sumás después desde Dominios.
  • Cada push a la rama elegida vuelve a desplegar.
  • Si algo falla, dice en qué paso y te lleva a la pestaña del servidor donde está el registro.

Antes de instalarlo

Usalo cuando

  • Tenés una web, una API o un front en un repositorio de GitHub y querés que quede publicada con HTTPS sin configurar un servidor.
  • Querés que cada push a una rama actualice lo que está publicado, sin entrar por SSH.
  • El proyecto es Node.js, un sitio estático (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) o trae su Dockerfile.

No es lo indicado si

  • Solo necesitás una base de datos o Redis: para eso están sus propias apps.
  • La aplicación ya está publicada como imagen en un registro: desplegala con Docker.
  • Necesitás varios servicios que arrancan juntos (app, cola, base): usá Docker con un Compose.

Cómo probar que quedó funcionando

  1. Abrí la dirección que se le asignó: Al terminar, la app muestra su dirección https. Abrila en el navegador o corré: curl -I https://tu-app.arducloud.com — tiene que contestar 200 (o la redirección que haga tu app).
  2. Hacé un cambio y subilo: Cambiá un texto, hacé git push a la rama desplegada y recargá la página: el cambio aparece cuando termina el despliegue. El registro de cada despliegue queda en el VPS, pestaña Deploy.
  3. Si es una API, llamá a un endpoint: curl https://tu-app.arducloud.com/health (o la ruta que tengas). Si contesta 502, la app no arrancó: mirá el log del servicio en el VPS.

Consejos

  • Antes de desplegar se muestra cómo se va a compilar, cómo se va a servir y a dónde apunta nginx. Revisalo: es más rápido corregirlo ahí que después.
  • Tu app tiene que escuchar en el puerto que recibe en la variable PORT, no en uno fijo.
  • En un sitio estático no queda ningún proceso corriendo: nginx sirve la carpeta compilada (dist, build u out).
  • Las variables de entorno y los secretos van en el VPS, no en el repositorio.
  • El dominio automático sirve para empezar; el tuyo lo sumás después desde Dominios, con su certificado.

Un flujo de deploy completo, sin YAML

La comodidad de una plataforma tipo Vercel, sobre un servidor que es tuyo.

  • Vinculás el repo desde el panel: Elegís un repositorio de tu cuenta de GitHub, la rama y un nombre de proyecto. Se verifica que la rama exista antes de crear el deploy.
  • Webhook automático: El webhook se crea solo en GitHub, con verificación SSL. No hay que tocar la configuración del repositorio.
  • Pull en cada push: Cada push a la rama seguida dispara un git pull en el VPS. Los pushes a otras ramas se ignoran.
  • Scripts antes y después: Un script previo al pull (por defecto descarta cambios locales) y uno posterior para instalar dependencias, compilar o reiniciar servicios.
  • Estado visible: Clonando, haciendo pull, compilando, reiniciando, online o error con el mensaje. Sabés en qué está cada deploy.
  • Historial de commits: Cada commit recibido queda registrado con SHA, mensaje, autor, fecha y archivos agregados, borrados y modificados, con enlace a GitHub.
  • Redeploy manual: Volvés a desplegar con un botón cuando lo necesitás, sin hacer un commit vacío.
  • La app completa en un lugar: Asociás al repo sus dominios, servicios systemd y tareas programadas, y ves toda la aplicación junta.
  • Varias ramas, un VPS: Un mismo repo se puede desplegar en ramas distintas dentro del mismo VPS: producción y staging lado a lado.
  • Sin YAML que mantener: No hay un archivo de pipeline que se rompa cuando cambia la sintaxis. Dos scripts de shell, que es lo que en la práctica termina corriendo igual.
  • Sin minutos de build: El build corre en tu VPS. No hay cuota de minutos ni cola de runners: el límite es la CPU que ya estás pagando.

Tu primer deploy en minutos

  1. Conectá tu cuenta de GitHub: Una sola vez, desde el panel.
  2. Elegí repo y rama: El código se clona en el VPS y el webhook se crea solo.
  3. Definí build y reinicio: Por ejemplo npm ci && npm run build y reiniciar tu servicio.
  4. Publicalo con dominio: Le asignás un dominio con HTTPS y cada push lo actualiza.
  5. Mirá el historial: Cada commit desplegado queda con su SHA, autor, mensaje y archivos cambiados. Si algo se rompió, sabés exactamente con qué.

Cómo funciona por debajo, y qué tener en cuenta

Lo que conviene saber antes de empezar, sin letra chica.

  • No hay un runner ni un agente de CI: el webhook de GitHub le avisa al VPS y el VPS hace git pull sobre el clon que ya tiene. Por eso el deploy tarda lo que tarde tu build y nada más.
  • El script previo al pull descarta cambios locales por defecto. Es a propósito: un archivo tocado a mano en el servidor es la causa más común de que un pull falle en medio de un deploy.
  • El script posterior es donde va todo lo tuyo: instalar dependencias, compilar, migrar la base, reiniciar el servicio systemd de la app.
  • Los pushes a otras ramas se ignoran. Un mismo repositorio se puede desplegar en ramas distintas dentro del mismo VPS, así que producción y staging conviven sin pisarse.
  • Cada combinación de repositorio y rama se despliega una vez por VPS.
  • Necesita systemd corriendo en el VPS. Está verificado en producción sobre Ubuntu 22.04 y es compatible con 18.04, 20.04, 24.04 y 26.04; en 16.04 no está disponible porque systemd 229 no arranca sobre un host con cgroup v2.
  • Hace falta la cuenta de GitHub vinculada con el token vigente. Si el token venció justo al eliminar un deploy, el webhook puede quedar colgado en GitHub y hay que borrarlo a mano.
  • El build corre en el VPS y usa su memoria. En el plan más chico conviene un repositorio liviano: compilar algo grande se queda sin memoria a mitad de camino.
  • Los administradores de la empresa editan y eliminan deploys; los miembros pueden verlos y crearlos.
  • Root real por SSH: el panel es un atajo, no una jaula. Todo lo que hace por botón también lo podés hacer a mano.

También se lo podés pedir a Claude, ChatGPT o Cursor

Todo lo que ves en el panel lo puede hacer tu agente de IA a través del servidor MCP de ArduMaker: con tu autorización, con el alcance que le des y con cada acción auditada. Ver qué hace el MCP

Deploy desde GitHub: preguntas frecuentes

¿Tengo que configurar el webhook en GitHub?

No. Se crea automáticamente al vincular el repositorio.

¿Qué pasa si hago push a otra rama?

Se ignora. Solo la rama configurada dispara el pull.

¿Puedo compilar y reiniciar mi app después de cada deploy?

Sí, con el script posterior al pull: instalás dependencias, compilás y reiniciás el servicio systemd de tu app.

¿Veo qué se desplegó y cuándo?

Sí. Cada commit queda registrado con autor, mensaje, fecha y archivos cambiados, con enlace a GitHub.

¿Sirve como alternativa a Vercel o Heroku?

Para apps que querés correr en un servidor propio, sí: tenés el mismo flujo de push para desplegar, pero con root, sin límites de funciones y con el precio fijo del VPS.

¿Necesito escribir un archivo de pipeline?

No. Hay dos scripts de shell: uno antes del pull y otro después. No hay YAML que se rompa cuando cambia la sintaxis de la plataforma.

¿Cuánto tarda un deploy?

Lo que tarde tu build. No hay cola de runners ni minutos de CI: el webhook avisa, el VPS hace el pull y corre tu script. La CPU es la que ya estás pagando.

¿Puedo tener producción y staging en el mismo VPS?

Sí. El mismo repositorio se puede desplegar en ramas distintas dentro del mismo VPS, cada una con sus scripts y su dominio.

¿Qué pasa si toqué un archivo a mano en el servidor?

El script previo al pull descarta cambios locales por defecto, justamente porque es la causa más frecuente de que un deploy se trabe. Si necesitás otro comportamiento, ese script lo editás vos.

¿Puedo volver a desplegar sin hacer un commit?

Sí, con el botón de redeploy. No hace falta un commit vacío para forzar el pull.

¿Qué frameworks detecta solo?

Al instalar el repo desde Apps se miran sus archivos y se propone cómo construirlo y arrancarlo: un Dockerfile se corre como contenedor; Next.js, Nuxt, Remix, Express, NestJS y SvelteKit (node) se construyen con npm y arrancan en el puerto 3000; Vite, Astro, Create React App y SvelteKit estático se construyen y se sirve la carpeta de salida; Django, FastAPI y Flask instalan requirements.txt y arrancan con gunicorn o uvicorn. Es una sugerencia: la confirmas o la cambias.

¿Cómo despliego una app de Django o FastAPI?

Vinculas el repo y la rama. Con manage.py se detecta Django y arranca con gunicorn; con fastapi en requirements.txt o pyproject.toml, FastAPI arranca con uvicorn en el puerto 8000. Las variables de entorno y el comando se ajustan en la configuración del deploy, la app queda como servicio que se reinicia sola, y el dominio va con SSL automático.

¿Puedo alojar mi propio servidor MCP o un agente que corra 24/7?

Sí. Un servidor MCP remoto o un agente es una app de Node o de Python como cualquier otra: la despliegas desde GitHub, le pones un dominio con HTTPS y queda corriendo como servicio, sin límite de tiempo de ejecución. Si trae Dockerfile, corre como contenedor.

Servicios que suelen ir juntos

Todo corre en el mismo VPS y se maneja desde el mismo panel.

  • Dominios y SSL: Subdominio gratis o tu dominio con Let's Encrypt, proxy nginx con vuelta atrás y redirecciones de puertos.
  • Servicios y tareas programadas: Creás servicios systemd para tu app y tareas programadas (tipo cron) con logs, sin escribir systemctl.
  • Docker: Activás Docker en un clic y administrás imágenes, contenedores, logs, volúmenes y redes desde el panel.

Del push a producción, en tu propio servidor Vinculá tu repo y dejá que cada commit se despliegue solo. No es un producto aparte: está en el panel de cualquier VPS de ArduMaker, junto al root real por SSH. Ver planes

Cómo funciona por dentro

La documentación técnica de lo que hay en esta página: qué hace cada herramienta, qué cambia, cómo se verifica y qué herramientas MCP la operan.

  • Deploy desde GitHub: Clona, construye y publica un repo de GitHub en el VPS; redeploy en cada push, historial por fases y vuelta atrás.

Toda la documentación

Compáralo con otras plataformas

Comparativas con datos públicos y fuentes, que también dicen cuándo conviene la otra opción.

Ver todas las comparativas