Hébergement Node.js — Déployez depuis Git, avec le CDN devant

Votre app Node, sans le serveur

Vous avez écrit l'app ; le pénible, c'est tout ce qui l'entoure — un VPS à mettre à jour, un reverse proxy à configurer, des certificats à renouveler, un gestionnaire de processus pour la garder en vie, et un CDN à brancher ensuite.

cdn.com.tr fait tourner votre app Node.js comme une application de conteneur gérée. Vous connectez un dépôt Git, et chaque push construit une nouvelle image et la déploie. Vous obtenez un domaine avec HTTPS automatique, des health checks qui redémarrent un conteneur en échec, des logs lisibles depuis le panneau ou la CLI, et la possibilité de faire varier les réplicas.

Comme cela tourne dans un conteneur, le runtime est celui que vous décidez : votre version de Node, votre gestionnaire de paquets, votre étape de build. Rien n'est caché derrière les réglages par défaut d'un panneau d'hébergement.

Next.js, NestJS, Express — tout ce qui se conteneurise

Il n'y a pas de liste de « frameworks supportés », parce qu'il n'y a pas de runtime imposé avec lequel être compatible. Si votre app se construit en conteneur et écoute sur un port, elle tourne ici.

Cela couvre Next.js et Nuxt côté front, NestJS, Express ou Fastify pour les API, et des workers qui ne servent jamais de HTTP. Un dépôt avec plusieurs services — une app web, un worker, une file — se déploie en plusieurs applications de conteneur depuis un seul fichier Docker Compose.

Vous gardez la main sur les détails qui cassent habituellement en hébergement mutualisé : version de Node, modules natifs, limites mémoire, et la façon dont le build s'exécute vraiment.

Déployer depuis Git

Connectez le dépôt une fois et choisissez la branche. Chaque push sur cette branche construit l'image et la déploie. Rien à téléverser, pas de SSH, pas de serveur de build à maintenir.

Il faut un Dockerfile dans le dépôt — c'est lui qui définit le build. Pour une app Node c'est un fichier court, et cela rend aussi le déploiement reproductible : le même commit produit toujours la même image. L'exemple ci-dessous suffit à la plupart des projets.

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 données, cache et stockage sans fournisseur supplémentaire

La plupart des apps Node ont besoin d'une base et d'un cache. Plutôt que de vous inscrire ailleurs et de coller des chaînes de connexion à la main, activez-les comme add-ons gérés : les identifiants de connexion sont injectés dans l'app pour vous.

Postgres, MySQL, Redis et NATS sont disponibles, plus un stockage objet compatible S3 pour les uploads et les fichiers statiques — le même stockage que sert le CDN, si bien que les uploads utilisateurs sortent par le edge et non à travers votre app.

Un seul panneau et une seule facture : app, base, cache, stockage, DNS, CDN et 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 100

Le CDN est déjà devant

C'est la partie que vous devriez sinon câbler séparément. Votre app est derrière le même réseau edge qui sert nos clients CDN : les fichiers statiques et les réponses cacheables sont servis depuis le edge le plus proche, avec compression Brotli et images WebP/AVIF automatiques — votre processus Node ne passe donc pas son temps sur des fichiers déjà envoyés.

Avec 4 points de présence en Turquie, les utilisateurs turcs sont servis depuis un edge dans le pays, tandis qu'un réseau de 14 pays garde le reste rapide. Un WAF, la protection DDoS, le filtrage de bots et le SSL automatique sont sur ce même edge — inclus, pas dans une offre supérieure.

Au déploiement, purgez le cache depuis la même CLI : `cdnctl purge --account <uuid> --path /assets/app.js`.

Staging, rollback et tarifs honnêtes

Les mises en production devraient être ennuyeuses. Vous pouvez créer une copie préprod d'une app, y déployer, vérifier, puis la promouvoir en production — et annuler la promotion si le résultat ne va pas. Les health checks repèrent un conteneur qui démarre sans devenir sain.

Les offres démarrent à 9 $/mois avec CDN, WAF, protection DDoS et SSL automatique inclus, plus 15 jours d'essai. Annulez quand vous voulez et gardez l'essai, ou demandez un remboursement le jour même. Facturation en monnaie locale avec facture turque et support 7/24.