Loading...

Deploy · 7 min de lecture

cdnctl init → deploy : du dossier de projet à l'URL en ligne

Voici le compagnon pratique du récit : chaque commande que vous taperez réellement, avec sa sortie réelle, de l'installation du CLI jusqu'au moment où votre app répond sur une URL HTTPS en ligne. Rien ici n'exige git, un registry de conteneurs ou une expérience préalable de Docker — les seuls prérequis sont un dossier de projet qui tourne en local et un plan avec la plateforme de conteneurs.

7 min de lecture Accessible aux débutants Mis à jour

cdnctl init → deploy : du dossier de projet à l'URL en ligne

Ce qu'il vous faut (60 secondes)

Une seule chose : un plan cdn.com.tr incluant la plateforme de conteneurs — tous les plans standard l'incluent. Installez le CLI avec la ligne ci-dessous et connectez-vous. Fonctionne à l'identique sur Linux, macOS et Windows ; il existe aussi des dépôts APT/YUM, Homebrew et une image Docker si vous préférez un gestionnaire de paquets.

installation + login
$ curl -fsSL https://cdn.com.tr/downloads/cdnctl/install.sh | sh
$ cdnctl login --email you@company.com

Étape 1 — cdnctl init : laissez le dossier se présenter

Lancez init dans le répertoire du projet. Il détecte la stack et le port, écrit un petit manifeste cdnctl.yaml, et dépose une section deploy dans AGENTS.md pour que votre agent de code IA apprenne le flux lui aussi. Il vérifie également votre compte : si la plateforme de conteneurs manque, il imprime le lien d'achat exact — et avec --wait, il se met simplement en pause jusqu'à ce que votre paiement se termine dans le navigateur, puis reprend tout seul.

cdnctl init
$ cdnctl init
Proje    : gorev-takip (node/express, port 3000)
Agent    : claude-code (claude on PATH), cursor
Paket    : ✓ Large (max 5 app)
Karne    : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı  : cdnctl.yaml, AGENTS.md

→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).

Étape 2 — cdnctl check : corrigez tant que c'est bon marché

check est un linter local de déployabilité. Les erreurs (elles casseraient le site en ligne) bloquent le deploy ; les avertissements non. Les correctifs tiennent généralement en une ligne : écouter sur 0.0.0.0 au lieu de 127.0.0.1, déplacer le token codé en dur vers --secret, ajouter un GET /health qui renvoie 200, lire le port depuis la variable d'environnement PORT.

cdnctl check
$ cdnctl check
[ERROR] bind-localhost (server.js:61)
        The app binds to 127.0.0.1 — unreachable inside a container.
        → Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
        A hard-coded secret (API key/token/password).
        → Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
        SQLite loses data on restart / multiple replicas.
        → Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
        No /health route — the platform can’t tell your app is alive.

Étape 3 — cdnctl deploy : un dossier entre, une URL sort

deploy archive le dossier (node_modules et .git ne voyagent jamais), l'envoie, le construit dans le bac à sable de la plateforme et le publie. Les lignes de progression veulent dire exactement ce qu'elles disent ; quand vous voyez LIVE, l'URL sert déjà en HTTPS. Les mises à jour sont la même commande — le nouveau build ne remplace l'ancien qu'une fois en ligne.

cdnctl deploy
$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
   build: running
   build: success        (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up

✓ LIVE: https://ca…….cdn.com.tr

Pas encore de plan ? La poignée de main navigateur

cdnctl init → deploy : du dossier de projet à l'URL en ligne — Pas encore de plan ? La poignée de main navigateur
La page d'achat, atteinte depuis cdnctl : le bandeau confirme la passation et le plan recommandé est marqué.

Si init ne trouve pas de plateforme de conteneurs sur votre compte, il vous envoie vers la page d'achat avec le contexte — la page affiche un bandeau confirmant que cdnctl vous y a envoyé et marque le plan recommandé. Payez dans le navigateur comme d'habitude ; la page de confirmation vous invite à revenir au terminal, et cdnctl (avec --wait, ou en relançant simplement init) reprend le flux automatiquement. Aucune clé à copier, aucune configuration.

Limites et petits caractères honnêtes

Les envois de source sont plafonnés à 128 Mo — largement suffisant dès que node_modules reste à la maison. Un build typique prend environ une minute. Si votre app doit conserver des fichiers, demandez un disque persistant au moment du deploy ou utilisez le stockage objet ; si elle utilise SQLite, envisagez plutôt la base de données managée — check continuera de vous rappeler pourquoi. Et si un build échoue, cdnctl imprime directement le log de build ; la cause la plus fréquente au premier essai est un Dockerfile qui copie node_modules depuis votre machine (ajoutez-le à .dockerignore).

Questions fréquentes

Puis-je rattacher mon propre domaine ?

Oui — l'app reçoit immédiatement un sous-domaine fonctionnel, et vous pouvez ensuite rattacher votre propre domaine depuis le panel ou le CLI.

Où sont mes logs ?

cdnctl container apps show et l'onglet Santé du panel couvrent l'état ; les logs de build sont imprimés par cdnctl deploy en cas d'échec, et les logs d'exécution vivent dans le panel.

Puis-je faire tourner plus d'une app ?

Oui ; votre plan fixe le quota d'apps. Chaque dossier de projet se déploie comme sa propre app avec sa propre URL.

Mon agent IA écrit le code — peut-il aussi déployer ?

Oui. init lui enseigne déjà les commandes via AGENTS.md ; donnez-lui un token deploy-only (cdnctl deploy-token create) pour qu'il puisse publier sans jamais détenir le mot de passe de votre compte.