Cloud in a Bottle:让自托管像手机一样简单

Cloud in a Bottle: making self-hosting accessible to everyone

Cloud in a Bottle:让自托管像手机一样简单

我对当前数字世界的现状感到沮丧:软件被广告、追踪和成瘾机制裹挟,与用户利益背道而驰。Cloud in a Bottle 旨在改变这一局面,它是一款开源个人云,让自托管体验像使用智能手机一样流畅。通过容器化应用、统一认证和精心设计的 API,它让安装和管理应用变得 trivial,无需成为系统管理员。我们提供托管版本以降低门槛,但开源自托管路径始终是一等公民。目前,我正在将我的数字生活迁移到自己的 Cloud in a Bottle 实例中,体验极佳。我们的目标是催化更多优质开源 Web 软件的诞生,让普通用户也能轻松拥有属于自己的数字家园。

自托管的感觉应该像使用一部能运行 Web 应用的智能手机,而不是一项系统管理员的副业。
  1. jiaosdjf

    云领域简直荒谬,我们袖手旁观了 20 年,任由 AWS 这类巨头定义了部署、认证甚至容器化的方方面面。

    容器化本该意味着“随处可宿”,字面意思就是随时能在任何云服务商那里重新部署一套复杂的服务及其连接。这才是该死的集装箱的意义:你开着卡车到世界上的任何港口,任何起重机都能把同一个集装箱吊上任何船只或卡车。

    亚马逊、谷歌、微软——这些人把供应商锁定(vendor lock-in)卖给了本该对此死磕到底的那部分技术社群。20 年前你 FTP 传几个 PHP 文件就能跑,现在你得搞懂 20 个 IAM 配置文件,把文件扔进各种桶里,因为一切必须开箱即用、具备百万级的扩展性。

    说真的,前几天我在搭建一个静态 Firebase 站点,只想在测试环境加个简单的密码保护(像 http auth 那样)给客户看。Firebase 试图把你锁进去的那些无用玩意儿里,连最基本的 http auth 都搞不定,搞得一团糟,还得启动一个 Cloud Run 实例之类的东西来检查静态密码。

    没错,我们 100% 需要修复托管模式,一切都应该可移植、简单、通用。

  2. KomoD

    这帮人一直在各个仓库里刷 issue 来推广这个项目,却完全没有披露他们与该项目有关联。

    https://github.com/search?q=%22cloudinabottle.toml%22&type=i...

  3. drunner

    我觉得这个领域的时机到了。人们想要摆脱订阅制、不再把个人数据租借给广告/AI 公司的意愿比以往任何时候都强烈。

    目前这个领域大多基于 docker compose,对许多本可能感兴趣的人来说简直无法触及。不管是不是这个项目,我希望很快能有个方案积累足够的势头,真正打破入门壁垒。

  4. jerf

    “我们(Imbue,我所在的公司)也提供托管版本,我认为这对让该项目广泛普及至关重要——这也为我们支持该项目提供了一个清晰的商业模式。”

    看了你们的托管页面,没看到任何关于备份的提及。我在文档里看到了备份的参考,但你们绝对应该提供某种开箱即用、明确标注的备份解决方案。配置难度是前端自托管的杀手,更新会让它随时间推移变得困难,但当一切崩溃而我手头没有备份时,就是我放弃的时候。

    我到处都找不到关于磁盘大小限制的说明。我能在上面托管 Immich 吗?能托管我的媒体服务器吗?费用是多少?肯定不是每月 10 美元就能托管我的媒体库吧。我不是囤积癖,大部分内容都是我亲自从自有媒体里转制的,这限制了大小,但你们每月 10 美元肯定还是托管不了。我看到应用列表里有 Jellyfin,但不知道费用是多少。部署页面上的 CPU 和内存限制我倒是能看懂。

    哦,我特指你们的托管服务。

  5. kolleraa

    这是个很棒的项目!是的,个人云时代来了,它将属于每一个人。

    我正在做一个目标相似但设计决策不同的项目——我不采用典型的容器,而是致力于开发瘦客户端应用,它们访问一个基于全无服务器架构构建的通用数据层。还没准备好投入生产,但感兴趣的话可以看看:https://starkeep.app/

  6. mawise

    这已经不是自托管最难的部分了,至少现在不是。这里的评论里有很多类似项目的例子,它们解决的基本上是同样的问题(应用选择和部署)。要让自托管变得“简单”,我们需要解决域名注册、DNS 管理和端口转发配置。

    这可能需要一个更像 OpenWRT 的项目,包含与注册商之间的 API 驱动关系。缺乏标准的(消费者可访问的)域名注册 API 是自动化这一过程中的巨大漏洞。如果这样的项目获得一些关注,它就可以迁移到物理路由器上,供未来的自托管者购买。如果域名注册、DNS 管理和端口转发都集成在路由器的软件中,那么剩下的难点就可以被充分自动化,让普通游戏机玩家也能轻松上手自托管。

  7. tgsovlerkhgsel

    这是个很棒的想法,祝它成功。自托管不应该是研究和设置 20 个不同应用的噩梦。

    有没有类似的东西正在为“科技公司技术栈”开发?也就是说,与其试图通过寻找 RPC 系统、权限/组管理器、凭证管理、存储、数据库、服务发现、作业管理、监控等来组装自己的定制基础设施,不如提供一个“有观点”的栈,你可以轻松部署,只要你接受他们的选择,所有这些部分都已经打包并连接好了。

  8. bob1029

    在自托管方面,人们声称的偏好和实际揭示的偏好之间似乎存在很大差异。

    往往看起来,向同伴展示自主的形象比真正实现自主更重要。

    一旦考虑到时间流逝和熵增等因素,复制 AWS 及其朋友们所做的一切需要耗费巨大精力。我从未能让一台媒体/NAS 设备存活超过 3-4 年。不可避免地会发生某种灾难性事件,我不得不从头开始,更换新供应商等等。即使没有数据丢失,这也让人厌倦。我向你保证,过一段时间你会受够的。你可能觉得这种事永远不会发生,然后某一天它就发生了。

    如果你真的负担得起使用云服务,你可以完成更多事情。我很难相信很多人通过自托管在总拥有成本(TCO)上真正赢了。

  9. skybrian

    这个提议有点意思,但就像 Sandstorm 一样,浏览预构建应用库让我有点提不起劲。这太像浏览一个非常小的移动应用商店了。可能只有三个应用我感兴趣。

    既然现在有 AI 了,我觉得 exe.dev 的提议更好:他们提供 Linux VM、Web 代理和集成。你可以让 AI 构建任何你想要的 Web 应用。我很想要 exe.dev,但希望能在我的 Mac Mini 上运行。

  10. pseudocomposer

    我真的不太理解它相比 Kubernetes 的好处在哪里?比如,有了现代代理和一个通用的 Kubernetes 集群(而且供应商多如牛毛),只要结构得当,一个好的 LLM 代理基本上能做任何你想做的事。

    再说了,像 Claude Code 这样的代理也有手机友好的 UI。

同日更多故事

2026-09-06