2026 年 3 月 23 日。如果你的 CI 管线里跑着 LocalStack 社区版，这天早上的构建全挂了。不是什么代码问题——LocalStack 当天切掉了社区版的免费通道，强制要求认证 token，安全更新同步冻结。付费起步价 39 美元/月/席位，CI 额度不在免费层里。开源项目、个人开发者、创业团队一觉醒来，本地 AWS 测试环境直接报废。
Reddit 上的反应相当激烈。开发者 alvsanand 的评论被多家科技媒体引用：说他们把 LocalStack 称为”开源实验”而不是完整项目，有种微妙的讽刺，毕竟 LocalStack 的整个声誉就是建立在开源基础上的。Hector Ventura 的团队就是被卡住脖子的那批人之一。
他没有写请愿帖，没有发牢骚长文，而是花了几个月从头写了一个替代品。叫 Floci，名字来自 floccus，一种看起来像爆米花的云层形态。
到 2026 年 7 月，这个项目已经积累了超过 1.1 万 Stars，1,145 次提交，69 个 AWS 服务的模拟覆盖，2,506 个自动化兼容测试。最新版本 v1.5.34，七天前刚发布。
说实话这种”一个人怒写替代品”的故事在开源圈不新鲜，大部分结局是热情退烧后仓库荒废。但 Floci 选的技术栈让它天然比别人跑得快，而且这个项目出生的时机恰好踩在一个巨大的市场真空上。
但故事归故事，数字不会骗人。看两组性能数据就知道这事值不值得当真。
性能数字才是真正的入场券
Floci 最唬人的数字不是 Stars，是 24 毫秒。同样的冷启动，LocalStack 需要 3.3 秒，差了 138 倍。空闲时 LocalStack 趴着吃掉 143 MiB，Floci 13 MiB。Docker 镜像 90 MB 对 1 GB。这些差距在本地开发时不明显，但放在 CI 管线上，每天几十次构建，每次拉镜像、等容器就绪，时间成本是实打实的。
一个真实案例：CloudHostReview 的工程师迁移 47 个集成测试，从 LocalStack 切 Floci，CI 总时间从 8 分 22 秒降到 4 分 51 秒，砍了 42%。工程师 Priya 的反馈很实在：“Floci 快到了让我们的开发者真的愿意在本地跑测试，而不是等 CI。”
性能差距的根因在技术选型。Floci 基于 Quarkus Native，走 GraalVM 编译成原生二进制，不需要 JVM 预热，一个约 40 MB 的独立可执行文件。LocalStack 是 Python 全家桶，语言选型决定了天花板。
另一个区分点是对”真实模拟”的态度。LocalStack 社区版的服务多是浅层 mock，返回固定响应，不真的跑容器。Floci 对 Lambda、RDS、ElastiCache、ECS、EKS、MSK 这些服务全部启动真实 Docker 容器：Lambda 函数真的在容器里执行，RDS 背后是真 PostgreSQL 和 MySQL 实例，ElastiCache 用真实 Redis 或 Valkey 跑 RESP 协议代理。这意味着你测出来的行为跟生产更接近，不会出现”本地全绿、上线就炸”的经典悲剧。
而且它是 MIT 协议。零认证、零遥测、零外部调用。对处理敏感数据的团队或者跑在离线环境的管线来说，这事比性能数字更重要。完全离线意味着 HIPAA、SOC 2 等合规环境不需要额外审计模拟器本身的数据流向。不过话说回来，MIT 协议虽然商业友好，代码质量目前基本是 Hector 一人在扛——这个事后面会细聊。
跑起来只需要 10 秒
Floci 的安装方式简单到让人怀疑是不是漏了什么步骤。一个 Docker 命令的事，端口 4566 跟 LocalStack 一模一样：
docker run -d --name floci -p 4566:4566 floci/floci:latest
如果你有一个用着 LocalStack 的 docker-compose，把镜像名从 localstack/localstack 换成 floci/floci:latest，其他什么都不用改。AWS CLI、boto3、Terraform 的 endpoint 配置全保持不变。这种零迁移成本的切换是 Floci 快速获取用户的核心原因，它故意选了完全兼容的路。
验证一下它确实在干活：
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://my-bucket
aws dynamodb create-table --table-name demo \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
存储模式值得单独提一下。Floci 有四种模式可选：
-
memory 最快但重启丢失，适合 CI 的一次性任务 -
persistent 同步写盘保证不丢数据，适合关键数据场景 -
hybrid 内存读加异步刷盘，日常开发的最优解 -
wal 预写日志加压缩，适合高写入吞吐场景
默认是 memory，我建议本地开发切成 hybrid，数据能在容器重启后幸存，又没有 persistent 那种每笔写入都等 fsync 的开销。切换只需要一个环境变量 FLOCI_STORAGE_MODE=hybrid，重启即生效。
需要 Docker 内部服务（Lambda、ECS 这些）的话，记得把 socket 挂进去：-v /var/run/docker.sock:/var/run/docker.sock。另外多账户隔离靠 12 位 AWS_ACCESS_KEY_ID 区分，跨账户测试不用起多个实例，这对测试跨账号 S3 访问、IAM 角色切换场景特别省事。
装好了、跑通了，自然要问：它适合你的场景吗？答案没那么简单。
什么时候用，什么时候再看看
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| CI/CD 集成测试 | 后端/全栈团队 | 启动快、零成本、MIT 协议 | ECS 任务生命周期未完全调和 |
| 本地开发调试 | 个人开发者 | 秒级启动、内存占用极低 | API Gateway v1 Terraform 兼容性有缺口 |
| Serverless 原型验证 | 创业团队 | Lambda+DynamoDB+S3 组合稳定 | Step Functions 等长尾服务待完善 |
| 开源项目 CI | 开源维护者 | 无需 token、不担心过期 | S3 CopyObjectAsync 在 v1.5.34 有回归 |
| 生产环境模拟 | 所有人 | —— | 不适合。生产环境请用真实 AWS |
不适合它的场景同样明确。如果你的项目重度依赖 CloudFormation，Issue 区有 8 个资源类型的覆盖请求挂着，Terraform CDK 工作流会碰到坑。如果你在用 API Gateway v1 搭配 OpenAPI 定义做 Terraform 部署，PutRestApi 接口目前只接受 JSON Content-Type，Terraform 发的是 octet-stream，直接 415，意味着管理面能建 API 但数据面调不通。
EKS 是另一条需要警惕的线。Floci 用 k3s 模拟 EKS，跑简单的 Pod 没问题，但不要指望它能复现生产集群的网络策略和 IAM 集成细节。ECS 也有类似问题：容器退出了但 ECS API 永远不会调和状态，aws ecs wait tasks-stopped 会永远挂住，这个 bug 对依赖 one-shot ECS 初始化任务的团队是硬阻塞。
关于合规：Floci 是纯粹的本地开发测试工具，MIT 协议完全商业友好，离线运行不产生外部调用。但要注意它不具备安全审计或合规认证，不适合用于正式的安全合规验证。
维护靠不靠谱
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~11,000+ | 2026 年 3 月创建，4 个月增速异常快 |
| 核心维护者 | 1 人（hectorvent） | Bus Factor 高风险，项目对单点依赖高 |
| Open Issues | 37 | 关闭 303 个，闭合比 89%，响应积极 |
| 协议 | MIT | 完全商业友好 |
单一维护者是最值得警惕的指标。Hector Ventura 响应速度确实快，有用户报告 S3 presigned URL 签名算法的 bug，他在周六下午 4 小时内修复发布。但这个强度显然不可持续，一个人同时处理 69 个服务的兼容性维护、社区 Issue、新功能开发，任何有开源项目维护经验的人都知道这个组合早晚要崩，除非社区里有人站出来分担。
社区方面有一些正向信号。合并的 PR 来自 11 个不同贡献者，项目已被 AWS Community Builders 计划接纳。Hector 本人对此的感慨很有意思：”我写了一个 AWS 的模拟器，然后 AWS 官方欢迎我加入社区。我一开始以为这两个世界不会有交集。”这种态度至少说明维护者的心态是开放的，不是一个闭门造车的人。
关于社区声音，Reddit r/floci 上一位用户 clickclickboo 的评价很直白：”Great work on this project, it’s super impressive. I would love to see an ability to enable true IAM for testing policies and overall security testing.”这个需求指向了 Floci 当前的一个结构性缺口：IAM 模拟是浅层的，不能真正用于权限策略的测试验证。对于需要测试 IAM policy 效果的团队来说，这还是一个未解决的问题。
不过总体趋势是向上的。v1.5 系列的主要精力花在了服务覆盖扩展而不是救火上，这是好信号。CloudFormation 的资源覆盖率是接下来的关键瓶颈，解决了这事，CDK 用户才能真正无痛切换过去。
我的真实判断
Floci 不是一个”用了就回不去”的神器。它是一个在正确时间、用正确技术栈、解决了正确痛点的务实项目。
时机占了决定性的比重。如果 LocalStack 没在 3 月砍免费版，Floci 大概率只是 Hector 硬盘上一个玩票性质的 side project。但 LocalStack 砍了，而且砍得很难看，于是数千个团队的 CI 管线同时断掉，市场需求像被捅破的水管一样涌出来。TechTimes 的报道直接用了”Floci Fills LocalStack’s $39/Month Paywall Gap”这个标题，精准得有点残忍。
它的技术护城河不在 Java 或 Quarkus，而在”真实容器模拟”这条路线。LocalStack Pro 的强项是服务覆盖广度，Floci 的强项是模拟深度。两者目前的竞争不在同一个维度上。如果你需要的是”80 个服务都有基本响应”，LocalStack Pro 更完整；如果你需要”S3、DynamoDB、Lambda 这三个的行为跟真 AWS 一模一样”，Floci 的 2,506 个全通过兼容测试反而是更强的保障。
但单维护者这个现实绕不开。再过 6 个月，如果 Hector 的精力开始分散，社区能不能接住后续的维护？目前看答案是否定的。贡献者虽然在增长，但没有出现能分担核心决策的第二人。局部来看，每个合并的 PR 都经过 Hector 的 review，每次 release 都是他一个人在推。这种模式在 20 个服务覆盖的时候还能撑，到了 69 个服务之后，每多一个服务就是多一个 class 的潜在兼容性问题。
我翻 Issue 区的时候注意到了一个模式：用户对稳定性问题的描述总是”这个 bug 在真实 AWS 上不存在，但 Floci 出现了”。兼容测试虽然数量可观，但每新增一个服务支持，就会带入一批新的边缘 bug。ECS 的僵尸任务问题、API Gateway v1 的 415 问题、Lambda 容器的连接问题，这些都是结构性的，不是修一个 if-else 能解决的。另外值得注意的是，目前所有的 Issue 都是 open 状态记录，说明社区反馈渠道畅通，但也意味着大量 edge case 等待消化。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/floci-io/floci |
| 官方文档 | https://floci.io |
| Docker Hub | https://hub.docker.com/r/floci/floci |
分析了这么多，核心问题只有一个：你现在该不该切过去？
先拿 Docker 跑起来，再决定要不要切
如果你现在用的是 LocalStack 社区版，切换几乎零成本，改一行镜像名的事。从 S3、DynamoDB、SQS、Lambda 这四个最常用的服务开始验证，确认你的测试通过率再说。
如果你用的是 LocalStack Pro 并且重度依赖 CloudFormation 或 API Gateway 的高级功能，别急着全量迁。先把 CI 管线里的冒烟测试切到 Floci，保留 LocalStack Pro 做完整回归。两套并行几个 sprint，看清楚缺口在哪。
说实话，这个项目最值得关注的不是它现在能做什么，是 Hector 在 LinkedIn 上画的那张大饼：Floci Cloud，团队共享的临时环境，按 PR 分配实例。如果这事做成了，它就不是 LocalStack 的替代品，而是一个新的品类。但目前 Floci 还处在”一个人硬扛一切”的阶段。好用，但脆弱。适合拿来跑测试，不适合拿来赌上线。这个判断在半年内大概率不会过时。