floci-io/floci

如果你写依赖 AWS 的代码，又不想为本地开发开账号、配 token 或买付费档，Floci 值得花时间试一下。但要记住：它覆盖的服务很多，你得针对自己真正用到的服务做验证，不能默认行为完全一致。

解决什么问题

开发者想在提交代码前跑一遍 S3、DynamoDB 或 Lambda 处理逻辑，通常要么连共享云账号、配凭证再清理资源，要么用一层很薄的 mock，结果和真实 AWS 行为越差越远。Floci 把这一步换成本地端点：现有的 SDK 和 CLI 请求指向 http://localhost:4566，资源就出现在本机。这样日常开发不用碰云账号，流程基本不变。

有什么不同

Floci 的思路是覆盖面加真实 Docker：README 说 Lambda、RDS、ECS、EC2、EKS 等服务跑在 Docker 里，不是浅层 HTTP mock；无状态服务由模拟器直接处理。存储可选内存、持久化、混合和预写日志，重启后保留多少状态由你决定。项目还带一套兼容性测试，覆盖 5 种 SDK 以及 Terraform、OpenTofu、CDK，共 2,576 个自动化测试，这是判断标准工具能否直接用的最有用证据。

代价是服务清单长不代表每个 API 的行为都一致。这些兼容性测试由项目自己提供，README 里的对比表也是作者的说法，包括启动时间和内存数字。如果你依赖细微的 AWS 语义，仍然可能遇到服务级差异。

谁值得试

适合：本地跑 AWS SDK 或 Terraform、想免登录直接用免费端点的开发者；需要在 CI 里准备 AWS 风格服务的团队；正在找替代方案、不想再为社区版配 token 的人。不适合：需要某个服务与生产完全一致、而该服务又不在兼容性测试覆盖内的团队，或者已经用着别的模拟器且没有迁移动力的团队。CLI 只是快速上手的一条路，README 也写了 Docker Compose 方式，并提供了 Terraform 指南。

使用条件与边界

Docker 是核心依赖：README 说 CLI 是最快路径，Docker 支撑的服务和 Web 控制台都依赖它。控制台 /_floci/ui 首次打开时会拉取一个 sidecar 容器，所以第一次访问需要网络和 Docker 网络配置。持久化和 WAL 存储模式要决定状态放在哪，切换模式会影响测试隔离。兼容性虽然经过测试，但服务表很长，动手前应先看 兼容性测试 里是否覆盖你用的 SDK 和工具。项目还公布了 控制台契约，自带界面不合适时可以换。

HotRepo 点评

HotRepo 的记录很有限：2026-10-24 为 27,096 星，2026-10-25 为 27,097 星，这期间两次进入日榜。这只是快照，不能证明热度持续，目前无法判断长期走势。项目创建于 2026-02-18。真要采用，先确认你实际用到的服务和 IaC 流程在兼容性测试里的覆盖情况，而不是只看测试总数。