Tu propio Vercel en un VPS: despliegues con Coolify y Dokploy

Vercel, Netlify y Railway hicieron que desplegar sea tan simple como hacer git push. El problema llega con la factura: cuando tienes varios proyectos, bases de datos, workers y tráfico que crece, el costo por proyecto y por uso se acumula rápido.

La alternativa que más me ha convencido es tener mi propia plataforma de despliegue en un VPS, con la misma experiencia de "push y listo". Hoy hay dos herramientas de código abierto que lo resuelven muy bien: Coolify y Dokploy.

Qué resuelven exactamente

Ambas son un panel web que se instala en tu servidor y se encarga de:

• Construir y desplegar desde un repositorio Git en cada push (con Dockerfile, Docker Compose o detección automática del stack).
• Proxy inverso y SSL automático con Let's Encrypt, sin tocar Nginx.
• Dominios y subdominios por aplicación.
• Variables de entorno y secretos por ambiente.
• Bases de datos listas con un clic (PostgreSQL, MySQL, Redis, MongoDB) y respaldos programados a S3.
• Logs, reinicios y rollback desde el navegador.
• Notificaciones cuando un despliegue falla.

En otras palabras: la parte de Vercel que usas a diario, corriendo en un servidor que pagas a precio fijo.

Coolify vs. Dokploy

Las dos funcionan muy bien. Mi recomendación: Coolify si quieres el catálogo más amplio de servicios en un clic y muchas opciones; Dokploy si prefieres algo más simple y con menor consumo. Las dos avanzan rápido, así que revisa sus versiones y funciones actuales antes de elegir.

Requisitos del servidor

• Un VPS limpio con Ubuntu o Debian. No instales esto sobre un servidor que ya tiene Nginx o Apache usando los puertos 80 y 443, porque el proxy de la plataforma necesita esos puertos.
• Al menos 2 vCPU, 4 GB de RAM y 40 GB de disco para trabajar cómodo. Funciona con menos, pero los builds de Next.js consumen bastante memoria.
• Un dominio con acceso al DNS.

Antes de instalar, aplica lo básico de seguridad: usuario sin privilegios, login solo con llave SSH y firewall con los puertos 22, 80 y 443 (lo detallo en mi post De localhost a producción sin llorar).

Instalación

Ambas se instalan con un script oficial. Como siempre que ejecutas un script remoto con privilegios, revísalo antes.

Coolify:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o install-coolify.sh
less install-coolify.sh        # revísalo
sudo bash install-coolify.sh

El panel queda en http://IP_DEL_SERVIDOR:8000.

Dokploy:

curl -sSL https://dokploy.com/install.sh -o install-dokploy.sh
less install-dokploy.sh
sudo sh install-dokploy.sh

El panel queda en http://IP_DEL_SERVIDOR:3000.

Lo primero después de instalar: crea la cuenta de administrador de inmediato (el primero que entra se queda con ella), asigna un dominio al panel para acceder por HTTPS y luego cierra el puerto del panel en el firewall.

DNS: un comodín y te olvidas

En lugar de crear un registro por cada aplicación, apunta un comodín al servidor:

Con eso, cualquier aplicación nueva puede usar nombre.apps.midominio.cl y la plataforma emite su certificado sola. Para los dominios "de verdad" de cada proyecto (como miproducto.cl) agregas su registro A apuntando al mismo servidor.

Si usas Cloudflare con el proxy activado (nube naranja), configura el SSL en modo Full (strict). Si la emisión del certificado falla, desactiva el proxy temporalmente para que Let's Encrypt pueda validar el dominio.

Desplegar una aplicación paso a paso

1. Conecta GitHub. Ambas plataformas permiten crear una GitHub App desde el panel: así acceden a repositorios privados y reciben un webhook en cada push.
2. Crea la aplicación eligiendo el repositorio y la rama (por ejemplo, main para producción y develop para staging).
3. Elige cómo construir: si el repo tiene Dockerfile, úsalo; si no, Nixpacks detecta Node, PHP, Python o Go y construye solo.
4. Define el puerto en que escucha la aplicación y el dominio.
5. Carga las variables de entorno.
6. Despliega y sigue el log del build en vivo.

Un Dockerfile que funciona bien para Next.js

Nixpacks sirve, pero con un Dockerfile propio controlas el tamaño de la imagen y el tiempo de build. Con output: "standalone" en next.config.js:

FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM node:22-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production PORT=3000 HOSTNAME=0.0.0.0
RUN addgroup -S app && adduser -S app -G app
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/.next/static ./.next/static
COPY --from=build /app/public ./public
USER app
EXPOSE 3000
CMD ["node", "server.js"]

Y uno para Laravel

FROM composer:2 AS vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --prefer-dist --no-interaction

FROM php:8.3-fpm-alpine
RUN apk add --no-cache nginx supervisor libpq-dev \
 && docker-php-ext-install pdo_pgsql opcache
WORKDIR /var/www
COPY --from=vendor /app/vendor ./vendor
COPY . .
RUN php artisan optimize:clear \
 && chown -R www-data:www-data storage bootstrap/cache
COPY docker/nginx.conf /etc/nginx/http.d/default.conf
COPY docker/supervisord.conf /etc/supervisord.conf
EXPOSE 80
CMD ["supervisord", "-c", "/etc/supervisord.conf"]

Para Laravel agrega en la plataforma un comando posterior al despliegue con php artisan migrate --force && php artisan optimize, y crea un servicio aparte para el worker de colas (php artisan queue:work) y otro para el scheduler.

Previews por pull request

Una de las funciones más útiles de Vercel también está aquí: al abrir un PR, la plataforma despliega esa rama en un subdominio propio (por ejemplo, pr-42.apps.midominio.cl) y lo elimina al cerrarlo. Ideal para que un cliente o el equipo revise cambios antes de mezclarlos. Ojo con la RAM: cada preview es un contenedor más corriendo.

Bases de datos y respaldos

Crear un PostgreSQL toma un clic, pero no lo expongas a internet: deja que las aplicaciones se conecten por la red interna de Docker usando el nombre del servicio. Si necesitas entrar desde tu máquina, usa un túnel SSH:

ssh -L 5433:localhost:5432 deploy@mi-servidor

Configura de inmediato los respaldos programados a S3 (o a un servicio compatible como Cloudflare R2 o Backblaze B2) y prueba una restauración. Un VPS es un solo disco en un solo lugar; sin respaldos externos, un error de disco o un borrado accidental es definitivo.

Lo que pierdes respecto de Vercel

Hay que ser honesto con los límites:

• No hay red global (edge). Tu aplicación vive en un datacenter. Para usuarios en Chile, un VPS en Sudamérica o en la costa este de EE. UU. funciona bien; para usuarios globales, pon Cloudflare adelante para cachear lo estático.
• Eres el equipo de operaciones. Actualizaciones del sistema, de la plataforma y de Docker son tuyas.
• Un servidor es un punto único de falla. Si se cae, se cae todo. Para proyectos críticos considera un segundo servidor o mantener esos proyectos en una plataforma administrada.
• Los builds compiten con las aplicaciones por CPU y RAM. Si un build pesado ralentiza producción, compila las imágenes en GitHub Actions, súbelas a un registro y que la plataforma solo las descargue.

¿Cuándo conviene?

• Sí conviene: varios proyectos propios o de clientes, APIs, workers y bases de datos, presupuesto predecible, y ganas de aprender lo que pasa bajo el capó.
• No conviene: un solo frontend estático que cabe en un plan gratuito, un equipo sin nadie que quiera hacerse cargo del servidor, o requisitos de alta disponibilidad que un solo VPS no puede cumplir.

Conclusión

Coolify y Dokploy le dan a un VPS la experiencia que antes solo tenían las plataformas administradas: push, build, SSL y dominio sin escribir una línea de Nginx. A cambio, asumes la operación del servidor. Para alguien que maneja varios proyectos y quiere costos fijos, es un intercambio que vale mucho la pena, siempre que no olvides lo aburrido pero vital: actualizaciones, firewall y respaldos fuera del servidor.