Aller au contenu

Déployer

Le push est le déploiement.

Une illustration animée de l'App Builder : un prompt est saisi dans un champ de texte, le bouton Construire est pressé, et l'agent énumère son plan — pages, modèle de données, base managée, push vers le dépôt — avant de se mettre au travail.

Décrivez une app et un agent l'écrit dans votre propre dépôt GitHub. Ou connectez un dépôt que vous avez déjà. Dans les deux cas, le push est le déploiement : un build tourne sur votre serveur de déploiement managé et une adresse en ligne revient.

Commencer à construire Voir un push se construire

01 Comment ça marche

Décrivez. Regardez-le se construire.

Un espace de travail relie un dépôt GitHub à une conversation. Vous dites ce que vous voulez ; l'agent écrit le code et le pousse ; votre serveur de déploiement construit le push et publie le résultat.

Six étapes : décrire, planifier, provisionner, construire, déployer, mettre en ligne. Un rail de progression se dessine au fil du défilement.

  1. 01 Décrire

    Dites ce que vous voulez

    En langage courant. Une landing page, une petite API, un site WordPress. L'agent demande ce qu'il lui manque encore, puis se met au travail dans votre dépôt.

  2. 02 Planifier

    L'agent établit le plan

    Les pages, le modèle de données, le parcours entre les deux. Chaque étape qu'il franchit est écrite dans la conversation : rien ne se passe hors de vue.

  3. 03 Provisionner

    Ce qu'il faut se met en place

    Une base managée est provisionnée avec l'app. Son URL de connexion devient une variable de config : l'app la trouve au démarrage suivant.

  4. 04 Construire

    Un push déclenche un build

    L'agent commite dans votre dépôt GitHub. Votre serveur de déploiement récupère le commit — clone, install, build — sans aucun fichier de pipeline à écrire.

  5. 05 Déployer

    Une release part

    Les variables de config et la base attachée sont reportées sur la nouvelle release. L'URL continue de répondre pendant la bascule.

  6. 06 En ligne

    Une URL revient

    L'app répond à sa propre adresse. Chaque push suivant la met à jour exactement de la même façon, et l'adresse ne change jamais d'une release à l'autre.

02 Pour les développeurs

Poussez, et c'est parti.

Connectez un dépôt et Interlaken prend la suite — clone, install, build, run. Les dépôts privés passent par votre propre compte GitHub connecté : aucune clé ne change de mains.

  • 01

    Push pour déployer

    Choisissez une branche. Chaque commit dessus est construit et publié ; aucun fichier de pipeline à écrire, aucun runner à maintenir.

  • 02

    Dépôts privés, votre compte

    Les dépôts privés sont clonés via votre propre compte GitHub connecté. Aucune clé de déploiement ne change de mains et rien n'est recopié dans la plateforme.

  • 03

    Désignez-le, choisissez un runtime

    Interlaken clone le dépôt, le construit et l'exécute. Apps web et services, sites WordPress — si ça se construit et écoute sur un port, ça tourne.

  • 04

    Journaux et historique dans la console

    La sortie du build, l'historique des déploiements et le journal d'activité de l'app sont sur la même page que l'app.

Une séquence animée : un commit corrige le total du panier, git push s'exécute, le journal de déploiement montre les étapes de build et de release, l'app se lève à son URL en ligne, et l'historique liste les releases précédentes.

03 Aller plus loin

Ça grandit avec vous.

Votre app n'est pas posée dans une boîte noire. Dessous, ce sont les mêmes primitives qui font tourner tout le reste d'Interlaken — et le jour où vous en avez besoin, elles sont à une page, pas à une migration.

01

Quand il lui faut de l'état

Attachez une base PostgreSQL, MySQL, MongoDB, Redis ou Elasticsearch managée. Son URL de connexion arrive dans l'app en variable de config ; l'app la trouve au démarrage suivant.

02

Quand il lui faut des réglages

Modifiez les variables d'environnement dans la console. Elles sont écrites sur la machine en marche et intégrées pour son prochain démarrage : rien ne dérive.

03

Quand une release est mauvaise

Chaque déploiement est enregistré avec son journal de build. Redéployez une version antérieure et l'app y revient — l'URL répond pendant toute l'opération.

04

Quand il lui faut votre nom

Chaque app démarre sur le domaine applicatif de votre serveur de déploiement. Pointez le DNS de votre propre domaine sur le serveur, ajoutez-le à l'app, et elle y répond aussi.

Dessous

  • De vraies machines

    Les apps tournent sur des machines virtuelles, des microVM Firecracker et des conteneurs que vous pouvez redimensionner, snapshoter, ouvrir en console et placer vous-même.

    Voir l'infrastructure

  • Un vrai réseau

    Réseaux privés et sous-réseaux, répartiteurs de charge qui parlent de TCP à HTTP/3, adresses publiques et sortie routée — le tissu sur lequel la plateforme tourne elle-même.

    Explorer la plateforme

  • De l'état managé

    PostgreSQL, MySQL, MongoDB, Redis et Elasticsearch en services managés, plus des volumes bloc répliqués et des buckets compatibles S3.

    Explorer la plateforme

04 Questions

Avant de commencer.

Les réponses courtes. Les longues sont une page de la console.

Non. Dans l'App Builder, vous décrivez l'app dans une conversation et un agent l'écrit et la déploie. Le code reste dans votre propre dépôt GitHub du début à la fin : vous pouvez le lire, le modifier ou le confier à un développeur quand vous voulez.

Rien à installer

Commencez par une phrase.

Créez un compte, décrivez ce que vous voulez exécuter, et laissez l'agent faire le premier passage. Vous payez ce que vous utilisez.

Commencer Voir les tarifs