Instantiate: Test Your Merge Requests Like Never Before

Picture this: you're reviewing a Merge Request (MR), staring at a diff, trying to decode what this new ButtonV2 is supposed to look like, and someone tells you "trust me, it works." Trust you? Really?

Now imagine a world where you can see the change, click through the app, test the behavior, and maybe even break it (just a little), all without deploying to staging or praying you didn’t just nuke production.

Welcome to the world of Instantiate.

A real-world need: testing before merging

When a developer opens an MR, they usually have a clear idea of what they’re changing. But communicating that change to others, especially non-devs, can be tricky. Developers are happy with diffs and stack traces. But product, UX, UI? They want visuals.

That’s where Instantiate shines: every time someone opens a MR, it spins up a full environment just for that branch. You get a live, clickable version of the app with the changes applied. Perfect for:

• Testing a new feature before it hits staging
• Validating a bugfix in an isolated setup
• Reviewing a UI redesign without playing "guess the padding"
• Letting your PO, UX designer, QA, or even Bob from security poke around, without touching Git

How it works (and why it won’t eat your weekend)

Instantiate uses a .instantiate/config.yml file at the root of your repo. This file describes your stack, frontend, backend, database, etc. and which ports to expose. Every time a MR is opened or updated, a webhook kicks in. It tells Instantiate:

1. Where to find the .instantiate/docker-compose.yml
2. How to dynamically inject variables (ports, URLs, paths)
3. How to build and launch the stack in a clean, isolated container
4. How to generate a unique URL for the instance (like https://instantiate.io:1234)
5. And finally: how to comment on the MR with links to test it live

Oh, and when the MR is closed (merged or abandoned)? The stack is automatically cleaned up. If the MR is reopened? The stack comes back to life. Like magic, but with YAML and Docker.

Code quality, because we like sleeping at night

At Instantiate, clean code isn’t a goal, it’s a lifestyle. We take our quality checks very seriously:

• Test coverage > 90%, otherwise we get hives
• Strict ESLint rules, because sloppy code makes us cry
• Prettier, so every file looks fabulous, even at 3AM
• CI checks on every commit, because “works on my machine” doesn’t cut it anymore
• Readable logs, for humans (not just log parsers)

Basically, if Instantiate went to a job interview, it’d show up in a three-piece suit with a JSON résumé and glowing references from ESLint.

Open source and proud of it

The project is fully open source and available here: https://github.com/valcriss/Instantiate

You'll find the code, documentation, open issues, and probably a few jokes hidden in the comments. Feel free to fork it, try it out, suggest improvements, or just take a look at how we handle the dark arts of dynamic port assignments in Docker.

Instantiate is still young, but it’s ambitious. It wants to make your MRs more interactive, more testable, and honestly, just more fun.

So, when are you going to instantiate?

Imaginez un monde où valider une Merge Request (MR) ne se résume pas à lire quelques lignes de code sur GitHub en espérant qu'elles fassent ce qu'on pense qu'elles font. Imaginez un monde où vous pouvez voir, interagir, tester et briser (juste un peu) ce qui a été développé, dans un environnement isolé, sans casser la prod ni réveiller l’équipe SRE en sueur à 2h du matin.

Bienvenue dans le monde d’Instantiate.

Un besoin bien réel : tester avant de merger

Lorsque quelqu’un pousse une MR, il ou elle a en tête un changement bien précis. Mais encore faut-il que ce changement soit compréhensible et validable par toutes les parties prenantes. Pour les développeurs, pas de souci : un diff et c’est parti. Mais pour les équipes produit, UX ou UI, c’est plus compliqué : on leur parle de padding à droite et de refacto du composant ButtonV2, mais ils veulent voir.

C’est là qu’Instantiate entre en jeu : à chaque MR ouverte, il déploie automatiquement un environnement dédié, dans lequel on peut naviguer sur la version à tester. Parfait pour :

• Recetter une nouvelle fonctionnalité sans attendre la mise en staging
• Valider un bugfix dans un environnement isolé
• Tester une refonte UI sans screenshots approximatifs
• Permettre aux PO, UX/UI, QA, ou à Tonton Gérard de la sécurité, de donner leur avis sans toucher au code

Comment ça marche (et comment ça se configure sans sacrifier votre week-end)

Le fonctionnement d’Instantiate repose sur un fichier .instantiate/config.yml à la racine du dépôt. Ce fichier décrit les services à lancer pour votre stack (frontend, backend, base de données, etc.) ainsi que les ports à exposer. À chaque MR ouverte (ou mise à jour), un webhook est déclenché. Celui-ci envoie toutes les infos nécessaires à Instantiate, qui va :

1. Récupérer le fichier .instantiate/docker-compose.yml
2. Substituer les variables dynamiquement (ports, URLs, chemins)
3. Démarrer la stack dans un container isolé (par exemple un frontend React, un backend Express, une base PostgreSQL)
4. Associer une URL unique à cette instance (genre https://instantiate.io:1234)
5. Commenter automatiquement la MR avec les liens pour tester

Cerise sur le gâteau : quand la MR est fermée (merge ou abandon), la stack est automatiquement supprimée. Et si elle est réouverte ? Re-déploiement automatique. Tout cela sans que vous ayez à lever le petit doigt (ni relancer un Jenkins bancal).

La qualité, c’est comme le café : on en veut toujours plus

Chez Instantiate, on a la religion du code propre. Le projet est développé avec rigueur et un soupçon d’obsession :

• Couverture de tests > 90%, sinon on ne dort pas la nuit
• Linting strict via ESLint avec des règles maison qui empêchent l’écriture de code douteux
• Prettier pour que tous les fichiers ressemblent à quelque chose, même à 3h du mat
• Tests automatisés sur chaque commit, parce que "ça marche chez moi" n’est plus une excuse
• Logs lisibles, même pour les humains

En gros, si Instantiate devait passer un entretien d’embauche, il arriverait en costume trois pièces, avec un test de personnalité et une lettre de motivation signée en JSON.

Open source et bien dans sa peau

Le projet est entièrement open source et disponible ici : https://github.com/valcriss/Instantiate

Vous y trouverez le code, la doc, les issues, et même quelques blagues dans les commentaires. Forkez, testez, proposez des améliorations, ou venez juste voir comment on a géré l’enfer des substitutions de ports dynamiques dans Docker.

Instantiate est jeune, mais il a de l’ambition. Il veut rendre vos MRs plus vivantes, plus testables, et franchement, plus fun à valider.

Alors, vous instanciez quand ?