Floci : l’alternative open source à LocalStack pour tester AWS en local

Tester une application AWS sans toucher à un vrai compte cloud reste un besoin très concret pour les équipes DevOps, les développeurs backend et les petites équipes SaaS.

On veut valider du code, des files SQS, des buckets S3, des tables DynamoDB, des Lambdas ou des plans Terraform sans générer de coût, sans créer d’environnement jetable dans AWS, et sans dépendre d’identifiants sensibles dans la CI.

Historiquement, LocalStack a largement occupé cette place. Mais le sujet revient avec force depuis que certaines limitations de l’édition communautaire, la question des tokens et les restrictions de fonctionnalités poussent des équipes à regarder ailleurs.

C’est dans ce contexte que Floci devient intéressant : l’outil promet un émulateur AWS local open source, gratuit, sans compte, sans token et utilisable avec les outils AWS habituels.

La promesse est séduisante, mais elle mérite une lecture pragmatique. Floci ne doit pas être évalué comme un jouet de développement.

Il faut le regarder comme un composant de workflow : local dev, tests automatisés, CI, validation IaC, reproductibilité et limites de compatibilité avec les vrais services AWS.

Contexte : pourquoi chercher une alternative à LocalStack

Quand une équipe développe sur AWS, elle finit vite par rencontrer le même problème : comment tester assez tôt sans dépendre d’un vrai environnement cloud ?

Un compte AWS de dev peut fonctionner, mais il ajoute des coûts, des droits IAM, des risques de mauvaise isolation et parfois une latence inutile dans les boucles de développement.

Un émulateur local répond à ce besoin en proposant des services “AWS-like” directement sur le poste développeur ou dans la CI. L’objectif n’est pas de remplacer AWS, mais de raccourcir la boucle feedback.

On peut lancer des tests fonctionnels, vérifier une intégration S3 ou DynamoDB, valider des commandes AWS CLI, ou exécuter une partie d’un pipeline Terraform avant de toucher à un vrai compte.

LocalStack a longtemps été la référence évidente pour ce type d’usage. Mais dès qu’un outil devient central dans une chaîne CI, ses conditions d’usage comptent autant que sa couverture technique.

Si l’émulateur demande un compte, un token, un niveau payant ou une contrainte de licence qui bloque certains scénarios, l’équipe perd une partie de l’intérêt initial : simplicité et reproductibilité.

Floci arrive donc avec un positionnement clair : rester léger, gratuit et open source. Le projet se présente comme un émulateur AWS local pour le développement, les tests et la CI.

Le dépôt GitHub annonce une approche sans compte, sans token et sans feature gates. Pour une petite équipe, ce positionnement peut suffire à justifier une évaluation sérieuse.

Diagnostic : ce que propose Floci

Floci expose un endpoint AWS local sur le port 4566, ce qui reprend le modèle familier des outils comme LocalStack.

L’idée est simple : on pointe l’AWS CLI, les SDK, Terraform, OpenTofu ou une suite de tests vers http://localhost:4566, puis on garde les commandes et les workflows habituels.

Les credentials peuvent être fictifs tant qu’ils existent, puisque l’objectif est de parler à l’émulateur local.

D’après la documentation du projet, Floci couvre plus d’une cinquantaine de services AWS.

On retrouve les briques classiques attendues pour tester une application moderne : S3, SQS, SNS, DynamoDB, Lambda, IAM, STS, KMS, Secrets Manager, API Gateway, Cognito, EventBridge, Step Functions, CloudWatch, RDS, ElastiCache, ECS, EC2, EKS, OpenSearch, CodeBuild ou encore Route53.

Le point intéressant est la séparation entre services en mémoire et services appuyés sur Docker quand la fidélité d’exécution compte davantage.

Lambda, RDS, Neptune, ElastiCache, MSK, ECS, EC2, EKS, OpenSearch ou CodeBuild peuvent s’appuyer sur de vrais conteneurs. Ce choix rend Floci plus ambitieux qu’un simple mock HTTP.

Le diagnostic de départ est donc positif : Floci coche les cases qui intéressent une équipe DevOps. Mais il faut rester lucide. Un émulateur AWS local ne garantit jamais une compatibilité parfaite avec AWS.

La bonne question n’est pas “Floci remplace-t-il AWS ?”. La bonne question est “Floci couvre-t-il assez bien mes scénarios de développement et de CI pour éviter des environnements cloud inutiles ?”.

Causes : les limites des émulateurs AWS locaux

Les émulateurs AWS locaux échouent rarement parce qu’ils sont inutiles. Ils échouent quand on leur demande le mauvais niveau de fidélité.

Tester une création de bucket S3, une file SQS ou une table DynamoDB en local est très utile. Valider un comportement réseau complexe, une politique IAM subtile ou une intégration managée très spécifique reste plus risqué.

La première limite est la compatibilité API. AWS évolue vite, les services ont des détails parfois peu documentés, et certains comportements ne se voient qu’en production.

Même avec un protocole compatible, un émulateur peut diverger sur les erreurs, les délais, la consistance, les quotas ou les permissions.

La deuxième limite est l’illusion de sécurité.

Un test local qui passe ne prouve pas qu’une policy IAM est bien calibrée, qu’un chiffrement KMS est correctement géré, ou qu’un service managé se comportera exactement pareil.

Pour une équipe sérieuse, Floci doit donc compléter les tests AWS réels, pas les supprimer.

La troisième limite est le périmètre. Un outil peut couvrir beaucoup de services, mais ton besoin dépend des opérations exactes utilisées. Pour un projet qui manipule S3, DynamoDB, SQS et Lambda, l’adoption peut être simple.

Pour un projet qui combine API Gateway, Cognito, IAM avancé, EventBridge et Step Functions, il faut tester plus finement.

Solutions : comment utiliser Floci dans un workflow DevOps

Le meilleur usage de Floci consiste à l’intégrer dans une pyramide de tests. En bas, les tests unitaires restent sans dépendance externe.

Au milieu, Floci permet de lancer des tests d’intégration rapides contre des services AWS locaux. En haut, quelques tests plus coûteux tournent encore sur un vrai compte AWS pour valider les comportements critiques.

En local, le démarrage peut passer par le CLI officiel ou par Docker Compose. L’approche Docker Compose reste intéressante pour une équipe qui veut versionner l’environnement de test directement dans le dépôt applicatif.

Elle rend le setup lisible, reproductible et facile à lancer dans un runner CI compatible Docker.

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"

Une fois Floci lancé, les outils AWS doivent pointer vers l’endpoint local. Le principe est volontairement simple : région quelconque, identifiants fictifs, endpoint local. Ce modèle évite de manipuler des credentials AWS réels dans les boucles de développement.

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

aws s3 mb s3://demo-bucket
aws dynamodb list-tables

Pour les équipes IaC, l’intérêt est encore plus concret. Une partie des plans Terraform ou OpenTofu peut être testée localement si les providers et les ressources utilisées sont compatibles avec l’endpoint.

Ce n’est pas une validation finale, mais c’est une étape utile pour détecter tôt les erreurs grossières de configuration ou de câblage applicatif.

Dans une CI, Floci peut servir de service sidecar. Le pipeline démarre l’émulateur, attend que le port 4566 réponde, exporte les variables AWS locales, puis exécute les tests d’intégration.

Cette approche évite de créer des ressources temporaires dans AWS pour chaque branche ou merge request.

Si tu utilises déjà Docker dans tes environnements de test, l’intégration de Floci est assez naturelle.

Pour structurer ce type de workflow côté infra, les mêmes principes que pour un processus d’industrialisation infra Linux avec Ansible s’appliquent : versionner, documenter, automatiser, puis limiter les écarts entre local, CI et préproduction.

Prévention : ce qu’il faut valider avant adoption

Avant de remplacer ou compléter LocalStack avec Floci, commence par cartographier les services réellement utilisés par ton application. Beaucoup d’équipes pensent “AWS” alors qu’elles utilisent surtout quatre briques : S3, SQS, DynamoDB et Lambda.

Dans ce cas, l’évaluation est simple et peut être menée rapidement.

Si ton application dépend de services plus complexes comme Cognito, API Gateway, EventBridge, Step Functions, IAM avancé ou RDS, il faut écrire des scénarios de test précis.

L’objectif est de vérifier les opérations exactes utilisées par ton code, pas seulement la présence du service dans une liste de compatibilité.

Ensuite, sépare clairement les tests locaux des tests de validation cloud. Floci peut devenir un accélérateur quotidien, mais les étapes de sécurité et de conformité doivent encore passer par AWS réel. Cette séparation évite les mauvaises surprises au moment de déployer.

Il faut enfin surveiller la maturité du projet. Floci est prometteur, mais l’adoption doit rester progressive : test sur un service, intégration dans une branche, ajout en CI, puis extension aux workflows plus sensibles.

C’est la même logique que pour tout composant d’infrastructure : on évite le big bang, on mesure, puis on standardise.

Checklist d’évaluation

Pour décider si Floci est une bonne alternative à LocalStack dans ton contexte, utilise une grille courte. Elle doit couvrir le besoin technique, l’intégration développeur, l’intégration CI, la compatibilité IaC et les limites de sécurité.

Cette checklist évite le piège du “ça démarre donc c’est validé”. Un bon émulateur AWS local doit réduire la friction quotidienne, mais il ne doit pas masquer les vrais risques de production.

Erreurs courantes

FAQ

Conclusion

Floci mérite clairement d’être évalué si ton équipe cherche une alternative à LocalStack pour tester AWS localement.

Son positionnement open source, sans compte ni token obligatoire, colle bien aux besoins des équipes qui veulent des tests rapides, reproductibles et faciles à lancer en CI.

Le bon usage reste pragmatique : Floci pour accélérer les boucles de développement et les tests d’intégration, AWS réel pour valider les comportements critiques.

Si tu travailles sur S3, SQS, DynamoDB, Lambda, Terraform ou des workflows CI, c’est un candidat sérieux à ajouter dans ta boîte à outils DevOps.