Tu app Node, sin servidor que mantener
Tú escribiste la app; lo tedioso es todo lo que la rodea: un VPS que parchear, un proxy inverso que configurar, certificados que renovar, un gestor de procesos que la mantenga viva y un CDN que añadir después.
cdn.com.tr ejecuta tu app Node.js como una aplicación de contenedor gestionada. Conectas un repositorio Git y cada push construye una imagen nueva y la despliega. Obtienes un dominio con HTTPS automático, health checks que reinician un contenedor caído, logs que puedes leer desde el panel o la CLI, y la posibilidad de escalar réplicas.
Como corre en un contenedor, el runtime es el que tú digas: tu versión de Node, tu gestor de paquetes, tu paso de build. Nada queda escondido tras los valores por defecto de un panel de hosting.
Next.js, NestJS, Express — cualquier cosa contenerizada
No hay una lista especial de «frameworks soportados», porque no hay un runtime impuesto con el que ser compatible. Si tu app se construye en un contenedor y escucha en un puerto, aquí funciona.
Eso cubre Next.js y Nuxt en el front, NestJS, Express o Fastify para APIs, y workers en segundo plano que nunca sirven HTTP. Un repositorio con varios servicios —una web, un worker, una cola— se despliega como varias aplicaciones de contenedor desde un único fichero Docker Compose.
Mantienes el control de los detalles que suelen romperse en hosting compartido: versión de Node, módulos nativos, límites de memoria y cómo se ejecuta realmente el build.
Despliega desde Git
Conecta el repositorio una vez y elige la rama. Cada push a esa rama construye la imagen y la despliega. Nada que subir, sin SSH, sin un servidor de build propio que mantener.
Necesitas un Dockerfile en el repositorio: eso es lo que define el build. Para una app Node es un fichero corto, y además hace el despliegue reproducible: el mismo commit produce siempre la misma imagen. El ejemplo de abajo basta para la mayoría de proyectos.
Dockerfile — a typical Node app
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production PORT=3000
COPY --from=build /app ./
EXPOSE 3000
CMD ["npm", "start"]Bases de datos, caché y almacenamiento sin más proveedores
La mayoría de apps Node necesitan una base de datos y una caché. En lugar de registrarte en otro sitio y pegar cadenas de conexión a mano, actívalas como add-ons gestionados y los datos de conexión se inyectan en la app por ti.
Hay Postgres, MySQL, Redis y NATS, además de almacenamiento de objetos compatible con S3 para subidas y estáticos — el mismo almacenamiento desde el que sirve el CDN, así que las subidas de usuarios salen por el edge y no a través de tu app.
Un solo panel y una sola factura: app, base de datos, caché, almacenamiento, DNS, CDN y WAF.
cdnctl — add-ons and deploy
cdnctl container addons enable-postgres --account <account_uuid> --app <app_uuid>
cdnctl container addons enable-redis --account <account_uuid> --app <app_uuid>
# object storage for uploads
cdnctl object-storage buckets create --account <account_uuid> --name uploads
# ship it
cdnctl container apps deploy --account <account_uuid> --app <app_uuid>
cdnctl container apps logs --account <account_uuid> --app <app_uuid> --tail 100El CDN ya está por delante
Esta es la parte que de otro modo tendrías que montar aparte. Tu app queda detrás de la misma red edge que sirve a nuestros clientes de CDN: los estáticos y las respuestas cacheables se sirven desde el edge más cercano, con compresión Brotli e imágenes WebP/AVIF automáticas, así que tu proceso Node no pierde tiempo con ficheros que ya envió una vez.
Con 4 puntos de presencia en Turquía, los usuarios turcos se sirven desde un edge en el país, mientras una red de 14 países mantiene rápido al resto. Un WAF, protección DDoS, filtrado de bots y SSL automático están en ese mismo edge — incluidos, no en un plan superior.
Al desplegar, purga la caché desde la misma CLI: `cdnctl purge --account <uuid> --path /assets/app.js`.
Staging, rollback y precios honestos
Los despliegues a producción deberían ser aburridos. Puedes crear una copia preprod de una app, desplegar ahí, comprobarla y luego promoverla a producción — y revertir la promoción si sale mal. Los health checks detectan un contenedor que arranca pero no llega a estar sano.
Los planes empiezan en 9 $/mes con CDN, WAF, protección DDoS y SSL automático incluidos, más 15 días de prueba. Cancela cuando quieras y sigue usando la prueba, o pide reembolso el mismo día. Facturación en moneda local con factura turca y soporte 7/24.
Preguntas frecuentes sobre hosting Node.js
¿Qué versiones de Node.js soportáis?
La que use tu imagen. El runtime sale de tu Dockerfile, así que eliges la versión de Node y la actualizas cuando quieras: no hay una versión de plataforma que esperar.
¿Tengo que escribir un Dockerfile?
Sí, hoy el repositorio necesita un Dockerfile (o un Docker Compose con sección build): eso define el build. Para una app Node típica son unas diez líneas; el ejemplo de arriba sirve para la mayoría. Además hace los despliegues reproducibles.
¿Puedo ejecutar varios servicios desde un repositorio?
Sí. Importa un fichero Docker Compose y cada servicio pasa a ser su propia aplicación de contenedor — web, worker, planificador. Las bases de datos y Redis de ese compose se convierten en add-ons gestionados en lugar de contenedores que tengas que cuidar.
¿Cómo funcionan los trabajos en segundo plano y el cron?
Un worker es simplemente otra app de contenedor sin puerto HTTP. Para tareas programadas hay jobs: una expresión cron que llama a una ruta de tu app, así que no necesitas un proceso planificador aparte.
¿El CDN va incluido o aparte?
Incluido. Tu app está detrás de nuestra red edge desde el primer despliegue — caché, compresión, WebP/AVIF automáticos, WAF, protección DDoS y SSL, todo en el mismo plan desde 9 $/mes.