Floci – émulateur AWS local gratuit et open source

• Floci est un émulateur AWS local gratuit et open source pouvant être lancé immédiatement, sans création de compte ni authentification, avec une architecture légère qui démarre via une seule commande
• Présenté comme une alternative sans restrictions en prévision de la fin de service en 2026 de l’édition communautaire de LocalStack, il autorise aussi l’usage commercial grâce à la licence MIT
• Très léger avec un temps de démarrage de 24 ms, 13 MiB de mémoire et une image de 90 MB, il affiche une vitesse 100 fois supérieure et une consommation mémoire 10 fois inférieure à celles de LocalStack
• Il prend entièrement en charge plus de 20 services AWS et garantit une forte compatibilité avec 408 tests SDK réussis sur 408
• Il suffit de changer l’endpoint dans le SDK AWS existant pour l’intégrer immédiatement, ce qui en fait une solution de remplacement directement exploitable pour les environnements locaux de développement et de test

---

Présentation de Floci

• Floci est un émulateur AWS local gratuit et open source, conçu pour être lancé immédiatement sans inscription de compte ni jeton d’authentification
• Il se lance simplement avec la commande docker compose up, sans restriction CI/CD ni verrouillage de fonctionnalités
• Son nom vient de cirrocumulus floccus, une forme de nuage, et le projet se présente comme « léger, doux et toujours gratuit »

Positionnement comme alternative à LocalStack

• L’édition communautaire de LocalStack doit prendre fin en mars 2026 ; ensuite, un jeton d’authentification sera requis, la prise en charge de CI sera arrêtée et les mises à jour de sécurité cesseront
• Floci est proposé comme une alternative sans restrictions à cette situation
• Distribué sous licence MIT, il peut être utilisé librement, y compris dans des contextes commerciaux

Comparaison des performances et des fonctionnalités

• Temps de démarrage d’environ 24 ms, 13 MiB de mémoire au repos et taille d’image Docker de 90 MB : l’ensemble reste extrêmement léger
• Par rapport à la version communautaire de LocalStack : démarrage environ 100 fois plus rapide et consommation mémoire plus de 10 fois inférieure
• Plus de 20 services AWS pris en charge, 408/408 tests SDK réussis
• Principaux services pris en charge :

  • API Gateway v2 / HTTP API**,** Cognito**,** ElastiCache (Redis + authentification IAM)

  • RDS (PostgreSQL, MySQL, authentification IAM), S3 Object Lock (COMPLIANCE / GOVERNANCE)

    • DynamoDB Streams, IAM, STS, Kinesis, KMS et d’autres sont entièrement pris en charge
    • Dans LocalStack, ces fonctionnalités sont partiellement prises en charge ou non prises en charge

Démarrage rapide

• Exemple de configuration docker-compose.yml de base fourni
  • Utilise le port 4566 et monte le répertoire local ./data
• Commande d’exécution :

  docker compose up
  

• Tous les services sont accessibles sur http://localhost:4566
• Les identifiants AWS peuvent être définis avec des valeurs arbitraires (AWS_ACCESS_KEY_ID=test, AWS_SECRET_ACCESS_KEY=test)
• Exemples de commandes :
  • aws s3 mb s3://my-bucket
  • aws sqs create-queue --queue-name my-queue
  • aws dynamodb list-tables

Intégration SDK

• Il suffit de modifier l’endpoint du SDK AWS existant pour l’utiliser tel quel
• Exemples par langage :
  • Java (AWS SDK v2) : endpointOverride(URI.create("http://localhost:4566";))
  • Python (boto3) : endpoint_url="http://localhost:4566";
  • Node.js (AWS SDK v3) : endpoint: "http://localhost:4566";
• Dans tous les exemples, region vaut us-east-1 et les identifiants utilisent la valeur "test"

Tags d’image

• latest : image native, recommandée avec un démarrage en moins d’une seconde
• latest-jvm : image basée sur la JVM, privilégiant la compatibilité multi-plateforme
• x.y.z / x.y.z-jvm : releases figées par version

Configuration de l’environnement

• Tous les réglages peuvent être redéfinis via des variables d’environnement préfixées par FLOCI_
• Variables principales :
  • QUARKUS_HTTP_PORT : 4566 par défaut
  • FLOCI_DEFAULT_REGION : us-east-1 par défaut
  • FLOCI_DEFAULT_ACCOUNT_ID : 000000000000 par défaut
  • FLOCI_STORAGE_MODE : choix entre memory, persistent, hybrid, wal (hybrid par défaut)
  • FLOCI_STORAGE_PERSISTENT_PATH : chemin du répertoire de données (./data)
• Documentation complète de configuration : configuration docs
• Réglages de stockage par service : storage docs

Licence

• Fourni sous licence MIT, avec une liberté totale d’utilisation et de modification sans restriction

[GN⁺]

Réactions sur Hacker News

• Ce serait bien que les fournisseurs cloud comme AWS, GCP ou Azure proposent officiellement des émulateurs pour le développement local
  J’utilise actuellement plusieurs stacks serverless AWS, et les tests d’intégration en local sont presque impossibles
  Localstack est une alternative correcte, mais ce genre de fonctionnalité devrait être fourni directement par AWS pour offrir une bien meilleure expérience développeur

  • Un émulateur local officiel semble séduisant en théorie, mais en pratique AWS devrait expliquer en détail toutes les différences de comportement de S3, IAM, Kinesis, etc.
    Les gens prendraient ces écarts pour des bugs AWS, et du point de vue d’AWS ce serait un cauchemar de support
  • J’ai vu le projet local-web-services, créé par un ingénieur AWS, et il offre des fonctionnalités assez similaires
    Il est aussi intéressant de voir Localstack subir la concurrence grâce à la tendance des outils d’infrastructure shift-left basés sur l’IA
  • Microsoft proposait autrefois Azure Service Dev Kit (ASDK), un bac à sable mono-nœud
    Cela a depuis été réduit, mais l’idée était d’imiter l’ensemble du cloud Azure en local
  • Je ne suis absolument pas d’accord avec cet avis
    Les logiciels devraient être conçus autour de l’abstraction et des interfaces, de façon à ne pas dépendre d’une API cloud spécifique
  • Cloudflare fournit un émulateur local pour sa plateforme serverless, et il fonctionne plutôt bien

• Ce type d’outil me semble être une tentative vaine
  Pour des tests unitaires, il vaut mieux mocker les appels AWS,
  et pour le développement local, il est plus sûr de provisionner un environnement de test réel avec des outils IaC comme Terraform
  Si le comportement de l’émulateur diffère du service réel, on risque de laisser des bugs passer jusqu’en production

  • En plus, on peut aussi se retrouver avec un effet inverse où du code ne fonctionne pas bien en local mais tourne correctement sur le vrai AWS

• Voici mon retour d’expérience et mes réflexions sur le concept de « AWS local »

  • Je ne pense pas que ce genre de produit aide beaucoup à attirer de nouveaux clients
    Quelqu’un qui rechigne déjà à enregistrer une carte bancaire ne deviendra de toute façon pas un gros client
  • Le free tier d’AWS est assez généreux. De mon côté, je ne dépense même pas 10 dollars par an
  • Pour apprendre AWS, il faut aussi vivre la réalité du contrôle des coûts. Mieux vaut se faire facturer 5 dollars au début que perdre 5 000 dollars plus tard
  • Le vrai avantage d’un cloud local, c’est de permettre des itérations rapides sans charge de sécurité
    Mais au moment du déploiement réel, il faut régler cette dette de sécurité, et c’est souvent là que le code qui « marchait sur ma machine » casse
  • Localstack bénéficie d’un soutien officieux d’AWS, donc il est riche en fonctionnalités et avance vite sur les releases
    Il sera probablement difficile pour une alternative FOSS d’atteindre ce niveau
  • Si j’ai besoin de ce type d’outil, c’est surtout pour l’émulation des permissions IAM
    Pour respecter le principe du moindre privilège, il faut souvent ouvrir les permissions une par une, ce qui finit par ressembler à un jeu de whack-a-mole des permissions
    Si on pouvait reproduire fidèlement IAM en local, cela raccourcirait énormément le cycle de déploiement
    Cette fonctionnalité existe dans la version payante de Localstack, donc je suis curieux de voir à quel point le nouveau projet l’implémente bien
  • En environnement CI/CD, Localstack est quasiment indispensable
    Il faut exécuter rapidement des centaines de tests d’intégration, et les vrais appels AWS sont peu efficaces à cause de la latence, des problèmes de cohérence, des coûts et des rate limits
    Donner un compte AWS à chaque développeur est aussi un cauchemar de gestion
    Dire qu’il faut « prendre soi-même une bombe de facturation AWS pour apprendre », c’est une analogie irréaliste, un peu comme dire qu’il faut se brûler pour comprendre le feu
  • L’objectif principal d’un émulateur local, ce sont les tests unitaires et certains tests d’intégration
    Si l’on donne un compte séparé à chaque développeur et qu’on configure seulement des billing alerts, les problèmes de sécurité ne sont pas si importants

• Je me demande en quoi ce projet diffère de moto
  Beaucoup de gens sont mécontents du changement de licence de Localstack, mais il existe déjà de bonnes alternatives
  La couverture des services de moto est impressionnante
  Notre équipe a failli migrer, mais nous restons finalement chez Localstack grâce à son contrat de support enterprise

• Cela semble assez utile pour les tests
  Je suis en train d’automatiser le packaging Lambda avec un rôle Ansible,
  et ce serait bien plus pratique si je pouvais mocker la vérification de l’existence d’un zip déjà présent dans S3

• L’édition communautaire de LocalStack doit s’arrêter en mars 2026, avec exigence de jeton d’authentification et arrêt des mises à jour de sécurité
  Floci est présenté comme une alternative sans ces contraintes

  • C’est dommage de voir cela se refermer après tant d’années, mais la licence enterprise que nous utilisions en entreprise était vraiment excellente
    Elle nous a fait gagner des milliers d’heures grâce à une boucle de feedback rapide, sans attendre les déploiements CloudFormation
    On pouvait même tester dans le train sans connexion Internet

• Le nom du projet est amusant, car en roumain il veut dire « petite boule de poils » et, en argot, poils pubiens

  • En latin, cela signifie « flocon de laine », et on le retrouve aussi dans l’expression flocci non facio, au sens de « chose sans valeur »

• C’est exactement le projet que j’attendais
  J’aime bien Localstack, mais je pensais qu’une solution open source portée par la communauté serait bien plus adaptée
  Si les ingénieurs AWS pouvaient y contribuer directement, tout le monde y gagnerait
  Avec l’adoption de l’IA qui s’accélère, les tests d’intégration en local deviennent indispensables

  • Mais du point de vue d’AWS, il n’y a aucune raison de soutenir un clone FOSS
    Il serait plus réaliste de fournir officiellement une version conteneurisée locale à la place
  • Tout à fait d’accord. Surtout maintenant que les workflows d’agents modifient réellement l’état des systèmes,
    les tests locaux sont le seul moyen sûr d’expérimenter des situations comme une « hallucination du modèle qui supprime une table »

• J’ai déjà utilisé Localstack et c’était plutôt convaincant
  Quelqu’un sait s’il existe quelque chose de similaire pour GCP ?
  bigquery-emulator m’a été utile,
  mais je n’ai pas encore trouvé d’émulation de l’ensemble de GCP

• Les fonctionnalités ont l’air intéressantes, mais il n’y a presque pas d’historique de commits, ni PR, ni issues
  Cela donne l’impression d’un projet généré automatiquement, donc difficile à considérer comme fiable
  Je ne suis pas certain qu’il soit sûr pour tester avec de vraies données

  • Je suis d’accord. Pour un projet OSS, il faut un minimum d’issues accumulées pour repérer des points d’entrée pour contribuer
    C’est encore très tôt, donc je vais simplement le garder à l’œil
  • C’est peut-être un projet vibe-coded
  • Je trouve exagéré d’avoir ce genre de soupçons pour un projet qui existe depuis à peine une semaine
    Avant, on croyait qu’en open source quelqu’un finirait bien par repérer les problèmes de sécurité,
    mais aujourd’hui on peut aussi lancer un audit de sécurité avec des LLM
    Ce n’est pas parfait, mais ce type d’audit automatique rend plus difficile la dissimulation de code malveillant