Modes de déploiement

bext prend en charge trois modes de déploiement qui couvrent tout, depuis un seul projet parallèle jusqu'à une flotte distribuée à l'échelle mondiale. Chaque mode utilise le même binaire : seule la configuration change.

Mode application unique (par défaut)#

Le moyen le plus simple d’exécuter bext. Pointez-le vers un répertoire contenant votre application framework et il gère le reste : détection, construction et service.

bext run .

bext lit bext.config.toml à partir de la racine du projet. Une configuration minimale suffit :

[server]
listen = "0.0.0.0:3061"
static_dir = "./dist/static"

[cache.isr]
default_ttl_ms = 60000
default_swr_ms = 3600000

Le mode application unique est le bon choix lorsque vous déployez une application par serveur ou conteneur. C'est également ce que bext dev utilise lors du développement. L'ensemble du cycle de vie de la demande (terminaison TLS, compression, SSR, mise en cache) se déroule au sein d'un processus unique sans aucune surcharge de processus inter.

Quand utiliser : projets solo, microservices derrière un équilibreur de charge, pods Docker / Kubernetes où chaque réplica exécute une application.

Mode multi-applications (hôtes virtuels)#

Lorsque vous devez servir plusieurs applications à partir d'une seule instance bext, passez en mode multi-applications. Définissez chaque application dans la table [apps] d'un fichier platform.toml et commencez par bext serve :

bext serve --platform-config platform.toml

[platform]
listen = "0.0.0.0:443"
data_dir = "/var/lib/bext"
max_apps = 50

[apps.marketing]
source = "/srv/marketing"
domains = ["example.com", "www.example.com"]
runtime = "nextjs"

[apps.marketing.cache]
default_ttl = "60s"
max_entries = 10000

[apps.blog]
source = "/srv/blog"
domains = ["blog.example.com"]
runtime = "hono"

[apps.blog.cache]
default_ttl = "300s"

[apps.api]
source = "/srv/api"
domains = ["api.example.com"]
runtime = "express"

bext achemine les requêtes entrantes en faisant correspondre l'en-tête Host à la liste domains de chaque application à l'aide d'un routeur hôte virtuel basé sur des trie. Chaque application dispose de son propre espace de noms de cache ISR, d'un limiteur de débit, d'un pool de tâches et d'une configuration facultative de plug-in par application.

Paramètres par application que vous pouvez personnaliser :

Quand l'utiliser : hébergeant plusieurs sites sur un seul VPS, une plate-forme interne en tant que service, des environnements de transfert dans lesquels plusieurs branches de fonctionnalités partagent un serveur.

Mode Edge (distribué avec Redis L2)#

Le mode Edge étend le mode multi-application ou mono-application avec un backend Redis partagé pour la synchronisation du cache sur plusieurs instances bext. Il s'agit d'une fonctionnalité Pro.

[server]
listen = "0.0.0.0:443"

[redis]
url = "redis://redis.internal:6379"
prefix = "bext:"

[cache.isr]
max_entries = 50000
default_ttl_ms = 60000
default_swr_ms = 3600000

Lorsque la section [redis] est présente et que url est résolue, bext active le mode cluster :

• Cache hiérarchisé L1 + L2 - DashMap en mémoire en tant que L1, Redis en tant que L2. Les hits L2 sont automatiquement promus en L1.
• Invalidation distribuée : l'invalidation des balises de cache est diffusée sur Redis Pub/Sub afin que toutes les instances soient purgées simultanément.
• Limitation de débit partagée : les compteurs de limite de débit utilisent Redis INCR afin que la limite s'applique à l'ensemble de votre flotte, et non à chaque instance.
• Cohérence des écritures : chaque écriture du cache ISR est conservée dans Redis de manière synchrone (configurable).

Lorsque Redis est inaccessible, bext se dégrade progressivement : L1 continue de diffuser le contenu mis en cache et les nouveaux rendus fonctionnent toujours. La reconnexion est automatique.

# Instance A (us-east)
REDIS_URL=redis://redis.internal:6379 bext run .

# Instance B (eu-west)
REDIS_URL=redis://redis.internal:6379 bext run .

Les deux instances partagent le même cache. Une page rendue par l'instance A est immédiatement disponible pour l'instance B via la couche Redis L2.

Quand utiliser : déploiements multirégionaux derrière un équilibreur de charge global, configurations à haute disponibilité où la cohérence du cache est importante, tout déploiement où vous avez besoin d'une mise à l'échelle horizontale au-delà d'un seul serveur.

Choisir le bon mode#

Vous pouvez toujours commencer avec le mode application unique et migrer ultérieurement vers le mode multi-applications ou Edge : les paramètres bext.config.toml restent inchangés.

En rapport#

• Guide multi-applications — procédure pas à pas détaillée pour héberger plusieurs applications sur une seule instance
• Mise en cache — TTL, SWR, cache hiérarchisé L1/L2 et protection contre la bousculade
• TLS et HTTPS — fourniture de certificats et comportement de redirection HTTPS
• Configuration : bext.config.toml — référence complète pour toutes les clés de configuration
• Opérations : mise à l'échelle — modèles de mise à l'échelle horizontale et planification de la capacité