Vire tes dev containers, passe à Devbox

Tu ajoutes un dev container à ton projet. Le build prend 10 minutes. Tu changes une dépendance. Rebuild. 10 minutes encore! Ton disque se remplit de layers. Ton filesystem est lent parce que tout passe par les mounts Docker

Un collègue arrive pas à le lancer parce que son daemon Docker a crashé. Un autre peut pas accéder à ses clés SSH parce qu’elles sont hors du container. Tu passes 2 heures à debug des volume mounts!

Devbox te donne des environnements isolés en quelques secondes. Pas de containers. Pas de builds. Pas de mounts. Tes outils sont là quand tu fais cd dans le projet

Les dev containers c’est de l’overhead cher

J’ai vu des équipes perdre des heures sur des problèmes de dev containers

Le container se build pas parce qu’une image de base a changé. Les volumes sont lents donc les tests prennent 3x plus de temps. T’as pas accès à tes dotfiles sans les copier dedans. Ta config Git fonctionne pas parce qu’elle est sur l’hôte!

Chaque membre de l’équipe doit avoir la même version Docker. Les mêmes settings. Les mêmes mounts configurés. T’en rates un et ça casse différemment chez eux!

Puis quelqu’un update le Dockerfile. Tout le monde rebuild. 15 minutes chacun. Toute l’équipe bloquée!

Ah, et tu utilises IntelliJ? Les dev containers nécessitent une licence Ultimate. VS Code l’a gratis. JetBrains te facture 169$/an pour le privilège d’utiliser un dev container. C’est 169$ pour rendre ton IDE plus lent!

Le vrai problème: les dev containers t’imposent un environnement arbitraire défini de manière impérative dans un Dockerfile. Faut tout build, tout lancer, attendre. Parfois ça plante au milieu

Ce que Devbox fait différemment

Devbox crée des shells isolés avec des packages Nix. Pas de virtualisation. Pas de runtime de container. Juste un shell avec tes outils

# Installation
curl -fsSL https://get.jetify.com/devbox | bash

# Dans ton projet
devbox init
devbox add go@1.21 nodejs@20 postgresql@15
devbox shell

T’as un shell avec Go 1.21, Node 20, et Postgres 15. Isolé de ton système. Ce sont les mêmes versions pour tout le monde!

La config c’est 10 lignes:

{
  'packages': [
    'go@1.21',
    'nodejs@20',
    'postgresql@15'
  ],
  'shell': {
    'init_hook': [
      'echo 'Environnement de dev prêt''
    ]
  }
}

Pas de Dockerfile. Pas d’étape de build. Pas de layers d’image. Nix télécharge les packages exacts dont t’as besoin et les met dans ton PATH!

C’est automatique avec direnv

Ajoute un fichier .envrc:

eval '$(devbox generate direnv)'

Lance direnv allow. Maintenant quand tu rentres dans le projet avec cd, ton shell charge tout automatiquement

cd ~/projet
# Environnement chargé automatiquement
go version  # 1.21
node --version  # 20

cd ~/autre-projet
# Environnement différent
go version  # 1.20 (ou pas installé)

Pas de commande devbox shell. Pas d’activation. Juste cd et tes outils sont là

Avec les hooks de shell, tu peux démarrer des services automatiquement:

{
  'packages': ['postgresql@15', 'redis@7'],
  'shell': {
    'init_hook': [
      'pg_ctl start -D .devbox/postgres',
      'redis-server --daemonize yes'
    ]
  }
}

Les services démarrent quand tu rentres dans le répertoire. S’arrêtent quand tu pars. Complètement automatique!

Pas de container = pas de problèmes de container

Ton filesystem c’est ton filesystem

Pas de mounts. Pas de drivers de volume. Pas de galères de permissions. Ton éditeur voit les vrais fichiers. Tout tourne à vitesse native!

Tes configs marchent

Git utilise ton .gitconfig. SSH utilise tes clés. Ton historique de shell persiste. Tes alias marchent. Tout est normal!

Pas de builds

Tu changes une dépendance? Tu l’ajoutes dans devbox.json. Tu lances devbox shell. Ça télécharge en quelques secondes. Pas de rebuild d’une image de 2GB!

Reproductible sans la galère

Nix fixe les versions exactes des packages. Ton collègue lance devbox shell et il a exactement les mêmes outils. Fini le ‘ça marche sur ma machine’!

Un client avait une app Django dans un dev container. Le build prenait 12 minutes. Docker Desktop utilisait 8GB de RAM. La moitié de l’équipe l’avait désactivé pour sauver la batterie

On est passés à Devbox. Même version Python, même Postgres, même Redis. Temps de chargement: 3 secondes. RAM: usage système normal. Tout le monde a gagné en autonomie de batterie!

Quand t’as encore besoin de containers

Devbox c’est pas fait pour la prod. C’est pour le dev

Pour le déploiement, Devbox peut générer des Dockerfiles:

devbox generate dockerfile

Ça crée un container minimal avec tes dépendances exactes. Tu le build une fois pour le déploiement

Utilise Devbox en local. C’est rapide, natif, zéro overhead. Build des containers pour la prod quand t’en as vraiment besoin

Devbox marche avec tout ce que t’as déjà

T’utilises déjà Docker Compose pour les bases de données? Garde-le:

{
  'packages': ['nodejs@20', 'python@3.11'],
  'shell': {
    'init_hook': ['docker-compose up -d']
  }
}

Ton app tourne nativement avec Devbox. Les bases tournent dans Compose. Le meilleur des deux

T’as besoin de la spec exacte des dev containers pour la CI? Devbox génère ça aussi:

devbox generate devcontainer

Ça crée un dossier .devcontainer. Ceux qui veulent des containers avec VS Code peuvent l’utiliser. Les autres utilisent Devbox

Commencer

Installe Devbox:

curl -fsSL https://get.jetify.com/devbox | bash

Dans ton projet:

devbox init
devbox add python@3.11 nodejs@20
devbox shell

T’es dans un shell isolé. Python 3.11 et Node 20 disponibles. Tu sors et ils disparaissent de ton PATH

Ajoute direnv pour l’activation automatique:

devbox generate direnv > .envrc
direnv allow

Maintenant tu fais juste cd dans le projet. Tout se charge automatiquement!

Ton équipe clone le repo, lance devbox shell. C’est le même environnement pour tout le monde. Pas de Docker. Pas d’attente de build. Pas de debug de mounts!

Les dev containers résolvent le mauvais problème. Ils containerisent tout alors que t’as juste besoin d’outils identiques. Devbox te file des outils identiques sans te taxer avec un container

Ton laptop reste rapide. Ton filesystem reste normal. Tout est prêt en quelques secondes. C’est comme ça que ça devrait marcher!