Vous avez construit quelque chose, avec Claude, avec Cursor ou à la main. C’est ici que cela arrive en ligne. Vous poussez, vérifiez la Preview et mettez en ligne. Les serveurs sont dans l’UE, et c’est vous qui décidez qui voit la Preview.
Accès sur invitation
Le chemin
Vous obtenez un jeton, vous poussez votre dépôt, et la plateforme construit. Votre agent de codage peut prendre chacune de ces étapes en charge. Vous pouvez aussi les faire vous-même. Est construit un projet avec un Dockerfile ou un site statique avec un index.html.
Vous poussez, la plateforme construit. Chaque push construit, et ce qui est sur main l’emporte. La réponse au push dit si le build a réussi.
Chaque changement arrive d’abord à une adresse de Preview. Vous le voyez là. Qui d’autre le voit, c’est vous qui en décidez.
Quand la Preview est bonne, vous la mettez en ligne d’un bouton. Si quelque chose tourne mal, un bouton ramène la version précédente.
Sans agent, il vous faut un jeton de votre projet et un second remote dans votre dépôt. Puis git push.
Ce qui tourne ici
Chacune tourne comme app sur cette plateforme, construite et livrée comme la vôtre, en conteneur sur le port 3000, d’abord en Preview, puis en ligne. La plupart calculent sur votre appareil et pas chez nous. transfer garde les fichiers pour le destinataire.
Spiral Galaxies, générées et résolues dans le navigateur.
Un sudoku comparatif qui calcule dans le navigateur.
Des codes QR, générés sur votre appareil et pas chez nous.
Un relevé de temps qui calcule sur l’appareil.
Remettre des fichiers. Envoyer demande un compte, recevoir non.
Chacune a un backend en Go. Les services de la plateforme elle-même tournent en Go, Rust, Elixir et Java.
Pour qui
Vous avez construit avec Claude ou Cursor quelque chose qui fonctionne, et vous voulez le mettre en ligne sans apprendre l’hébergement. Vous poussez, la plateforme construit et vous montre la Preview. Vous mettez en ligne une fois que vous l’avez vue.
Vous voulez un site que vous entretenez vous-même. Vous voyez chaque changement d’abord dans une Preview, puis vous le mettez en ligne.
Vous voulez déployer et ne pas exploiter de serveurs. Ce que la plateforme attend de votre code tient en cinq phrases sur une page.
Vous suivez plusieurs projets clients. Chacun a ici son propre projet, avec son code, sa Preview et son équipe, et les données de tous les projets sont dans l’UE.
Quelqu’un chez vous entretient le site lui-même. Le changement est dans la Preview avant que quiconque ne le voie, et les données restent dans l’UE.
Pourquoi ici
Tous les composants tournent sur des serveurs dans l’UE, les machines en Allemagne, le stockage objet en Finlande. Aucun fournisseur cloud américain n’est impliqué, le CLOUD Act ne s’applique pas, et vous n’avez pas à expliquer à vos clients un traitement de données aux États-Unis.
earl.ee est construit et livré sur earl.ee. Un logiciel reflète l’organisation qui le construit (loi de Conway, 1967). Les grandes plateformes cloud reflètent de grands groupes, leurs frontières entre services deviennent des frontières entre systèmes, et vous payez cette complexité. earl.ee n’a pas de services.
Accès
La plateforme est en alpha. Elle porte déjà son propre développement.
L’accès se fait sur invitation.
Vous recevez une invitation de quelqu’un qui travaille déjà ici.
Abus: abuse@earl.ee · Sécurité: security@earl.ee · Tout le reste: earl@earl.ee