大多数人都在使用第三方云服务提供商，他们非常致力于保护其服务的安全。主要的开销是保持 Discourse 本身是最新的，很多人都能做到这一点（事实上，使用 Discourse 的大多数站点都是自己管理的！）。
即使是真正的在自己家里的电脑上托管……你必须对安全性多加关注，但这绝对不是每年“数十万美元”那种复杂程度。
不过，在可能的情况下付费给我们托管，确实是支持我们对 Discourse 工作的绝佳方式！
10 个赞
无论您是运行自己的硬件，还是在云服务器上运行虚拟硬件，情况都是一样的。运行自己的硬件会引入额外的硬件故障因素，但维护云服务器的基本难题是相似的。您能回答以下问题吗：
- 您的防火墙允许哪些端口进入您的虚拟硬件？
- 您的防火墙允许哪些端口从您的虚拟硬件传出？
- 如果您允许端口 80 和端口 443 传出，您是否限制传出连接可以访问的网站？
- 攻击者会使用哪些七种最有可能的黑客策略，通过 Web 服务器渗透您的虚拟硬件，以及您如何防范每一种策略？
- 您的系统管理策略是什么，以便知道您的机器是否遭到入侵？
我可以继续说很久，但大多数管理自己云服务器的人对这类问题的回答都不够好。现在有了人工智能，黑客的复杂性将变得越来越强。
您的云托管服务提供商是为您提供一个可以安装 Discourse 的虚拟计算机，还是他们是专门的 Discourse 托管提供商，只为您提供对其维护的服务器上的一个 Discourse 实例的访问权限？
另一个话题：我们对 Facebook 也有同样的经历，但在我的案例中，他们甚至没有给我发送“您赢得上诉”的电子邮件。我的帐户突然恢复了正常，现在 Facebook 表现得好像什么都没发生过一样。在我的安全设置和活动日志中没有任何事件记录。现在我明白了 Facebook 不会保护我们创建的内容，我受到了严重的精神创伤，我与 Facebook 的关系也永久地改变和受损了。
1 个赞
没错。尽管我不应该为自己辩护（更不用说要接受“考验”了😅），但我还是想向您保证，我的设置的安全性并不由我来承担🤣
我也是。我一直清楚地认识到，脸书可以任意决定任何账户或社区的生死存亡，但亲身经历后，感受是完全不同的。
4 个赞
您没有解决我提出的问题，而是在回避它。您有权这样做。我已经清楚地表达了我的观点，您欢迎忽略它。
承认 FB 可以暂停我们的账户是一回事。那已经够糟糕了，但我认为大多数人都理解并接受这种风险。但是，当他们删除历史内容时，他们就越过了一条神圣的底线。他们删除了两年的研究数据，其价值远远超过了我个人账户的价值。他们使一个由 15K 多个用户组成的群体陷入混乱。这种情况是无法挽回的。
1 个赞
是的。我的意思是社区组织，而不是网站的组织方式。它们是相互独立的——你正在组织你的社区迁移到 Discourse，这本质上是一场运动。
我看了上面，没有看到任何关于这方面的内容——你有什么想法？也许我们可以关注可操作的方面——如何将你的想法付诸实践，或者为你的指明正确的方向。我想知道接收更集中的回复是否能帮助缓解只接收更多信息或被迫做出更多选择的感觉。如果我对此有所贡献，或者我的招募成员的建议听起来很武断，我深表歉意。
2 个赞
Steph 的评论 “我的设置的安全性不取决于我的责任” 听起来更像是她有一个系统管理员类型的人在协助安全方面。
我可以通过在我的配置中做一些探查来回答其中一些问题。对于其他一些，我没有经验。也许您能为那些没有六位数预算的自托管用户撰写一些安全提示？我相信这会受到欢迎。
8 个赞
你查看过 Structuring an active support community migrating from Facebook 吗？其中包含了一些相关内容，但大部分内容正在我与团队的讨论中进行，我一直在努力在这里收集技术知识。
正如我在本帖开头对 @awesomerobot 的回复一样，我意识到我到目前为止可能没有在正确的“层面”上陈述我的问题：
——我已开始改变这一点，例如 徽章，徽章，我的天哪！
没关系，你没有全部的背景信息，而且我可能没有很好地传达我的问题到底出在哪里。这种情况时有发生！我真的很感谢你愿意提供帮助和支持 
4 个赞
哦，我没有！太棒了，我很高兴分享我们处理你列出的一些想法的方法。我认为我之前的评论已经引向了那里已经发布的内容，所以我在这里退后一步，以免占用更多空间 
5 个赞
@stephtara 我理解，深入研究 Discourse 实例中看似无休止的配置选项可能会让人不知所措，但选项多也意味着机会多。话虽如此，在我阅读您的主题和帖子时，有两个反复出现的想法：
首先
“我们塑造工具，工具也塑造我们”，是的，我想我们可以同意 Facebook 不再以一种令人满意的方式塑造我们。您似乎更喜欢 Discourse，但却抱怨这个过程，并要求更少的选项和/或更简单的配置过程。尽管这对某些人来说可能很酷，对许多人来说是可取的，但这是 Discourse，而不是 Facebook 或其他被认为更容易使用的服务。我的建议是，直接着手建立您的 Discourse 社区吧。对于您在建立社区的过程中，非常受欢迎且备受赞赏的对 Discourse 的雄辩批评，以后有的是时间。
其次
我完全同意 @jenmck 的观点 
。正如一位前同事过去常说的“嘿，菲尔，别让完美成为良好的敌人”，目的是把我从细节中解脱出来，提醒我关注大局。别把它弄得太复杂，保持简单，直接开始做吧。
我关于直接开始的建议：
- 让邮件回复系统正常工作。
- 不要添加太多分类或标签。只添加一个标签，供所有来自任何 Facebook 群组的人使用。
- 添加三个群组，每个 Facebook 群组对应一个。
- 邀请您现有的 Facebook 员工/版主加入他们各自的群组。您文笔出色，请为每个群组和自动创建的员工群组/分类撰写合适的欢迎信息。
- 在 Facebook 上发布适当的通知，发出上述邀请。注意：邀请是特定于群组的，如果某些用户在多个 Facebook 群组中担任员工/版主，他们可能会收到多个邀请。
- 在 Discourse 上的员工群组中处理所有结构讨论。
- 您的一些 Facebook 员工/版主不会立即加入。没关系，继续建设，并在您努力摆脱 Facebook 的过程中鼓励他们加入。建设起来，他们就会来……或者不来。
- 在执行上述操作后不久的某个时间点，使用邀请流程和另一套精心撰写的消息（Facebook 和 Discourse）向您的 Facebook 成员发出公开邀请。并非所有 Facebook 用户都会立即加入。继续督促……建设起来，他们就会来……或者不来。
- 只是在您的 Discourse 实例上“发布一些内容”。
关于您的视频和文档：
- 如果您还没有这样做，请创建一个 YouTube 频道，其中包含所有视频。为每个视频在 Discourse 中创建主题/帖子会很费力，但一旦完成，您可以非常整齐地索引和组织内容。
- 文档目前最好放在别处。有很多选择。我的首选是从像 Hugo 这样的静态网站提供服务。
看到您在启动 Discourse 社区时遇到困难，这让我和其他一些人感到痛苦。Meta 上有很多人关心您的成功。您和您的员工/版主可以随时在这里寻求帮助。
4 个赞
我想他是这个意思。我从 2017 年开始帮助自托管用户，其中一些人非常不负责任（比如多年不升级任何东西）。由于我很大一部分收入是支持自托管用户获得的，我当然有不同的看法。
我遇到的唯一安全问题是有一个管理员，他做的事情包括用 CSS 在主题组件中隐藏元素，然后收费“修复”它。他还用 rails 控制台执行了 Post.destroy_all，结果删除了很多帖子。（我设法从备份中恢复了至少大部分帖子。）我没有听说过有人数据库被盗（除非是被受雇访问数据库的人盗取的）。
Discourse 在安全性方面做得非常出色。运行 WordPress 比运行 Discourse 危险得多。我不认为任何人应该这样做。
4 个赞
我并不是说自己托管 Discourse 需要深厚的计算机安全专业知识。但是当我读到这样的内容时：
这确实引起了我的警惕。
不是因为寻求帮助有什么不对，而是因为它暗示了一种设置，其中持续的访问和责任取决于一个特定的人是否可以随时提供帮助。在这种情况下，托管解决方案通常更合适。您仍然不需要自己登录服务器，但您会有一个可靠的后备方，而不是依赖于善意、空闲时间或在出现问题时依赖那个人是否可以提供帮助。正如我们不能依赖 Facebook 作为长期保证一样，我们也看到整个社区仅仅因为掌握密钥的那个人不再接电话而失败。
实际上，正是在出现问题且那个人变得无法联系的时候，人们才会来找我们（或找 Jay，或找 CDCK），尽管也许我只是在向自己人布道。
但我可能偏离了实际主题。我认为 @philh 的说法比我能说的要好
循序渐进。它不必立即完美。实际上，没有人知道对您的特定社区来说，“完美”是什么。您和您的社区会在此过程中弄清楚。如果您因为缺乏关于如何做某事，甚至不知道有哪些可能性而受到阻碍，那么 meta 是提问的完美场所，而且我不知道还有其他产品拥有如此棒的社区可以依靠。
7 个赞
或者，也许这只是意味着我还没有做，因为我把所有“Discourse”时间都花在了翻阅管理界面和在元（meta）社区闲逛上，我还在从今年早些时候的一场事故中恢复，这场事故加剧了我本已存在的执行功能障碍（你好，ADHD），而且在过去几周里，随着我重返工作岗位、生病的猫和生活本身，我几乎是勉强维持着。而且，“第一次做某事”的门槛比你想象的要高，这与要做的事情的实际内容关系不大。
我没有自己进行安装也是出于同样的原因：我本可以弄明白，但我正处于 a) 人生阶段和 b) 当前情况下，我正在对将精力花在哪里进行策略性选择。
对我来说，整个帖子都在偏离主题，而且已经有一段时间了。我发帖是想谈谈我发现的让我的新 Discourse 管理员体验比我认为的更困难的事情，而且（对相关人员没有恶意）我感觉自己正因为我的社区管理和技术专长及技能而受到质问。
6 个赞
没必要为自己辩解。我只是想指出可能阻碍你的事情。
作为这个社区的一员已有13年了，我不认为这里发生了这种情况。通常情况下，当有人寻求帮助时，人们自然而然地会提供做什么和如何做，即使只要求了其中一项。当收到的建议并非明确要求时，很容易让人感觉比预期的更具个人色彩或带有评判性。
5 个赞
大家好，我的经验不如在座的各位，但我从零开始（在同事的技术帮助下，因为是自托管）建立了一个 Discourse 社区。我对此非常满意，但确实我一直严格遵循这个：
我一步一步地实施新功能，但仅在需要时才实施。我总是在 Meta 上找到帮助，我数不清这个论坛拯救了我多少次 
完全正确。
我的社区刚刚满三岁（尽管我早一年前才开始学习 Discourse），如果我现在要更换平台，调整所有内容将会复杂得多。
为此，我发现包含一个新手教程非常有用，我在其中向新成员解释如何调整他们个人资料中的通知，以及如何发帖、搜索、反应和填写个人简介等其他基本操作。正是因为这个原因
很棒的建议 
感谢分享 @stephtara，我希望一切顺利，最终你也能在这里分享你很棒的 Discourse 社区（顺便说一句：我是一个十足的爱猫人士，也是一名前兽医，所以非常想更好地了解你的社区）。
10 个赞
我理解你的感受！我处于类似的情况，在我的 Discourse 之旅中可能比你落后大约两周。我有类似的在线系统背景（除了我是一名软件开发人员）。
你的帖子让我有点害怕，因为我正准备开始认真研究 Discourse，但我正在努力挤出时间。看来我将无法像我希望的那样零敲碎打地完成它。
无论如何，我只是想说我支持你，并在力所能及的范围内提供帮助！
8 个赞
感谢你的光临！你也是在从 Facebook 迁移现有的社区吗？在过去的几天里，我意识到这可能是我遇到的问题的关键因素，直到现在我才意识到这一点可能有点盲区。我计划在我有时间坐下来写点东西时，整理一下我对 Facebook 迁移问题的理解。
哎呀，很抱歉让你有这种感觉。但是的，时间绝对是需要的。我想这取决于你的“社区建设情景”。我想如果我“白手起家”建立一个社区（我可能真的会这样做，我有一些想法！），我早就用我已经设置好的东西大步前进了。
4 个赞
不，我不是要从 Facebook 迁移社区。相反，我正在从头开始建立一个社区。尽管如此，我仍然对可用的各种选项感到有些困惑。假期过后我才会认真对待这件事。
1 个赞
Discourse 确实有很多选项，但有条不紊地浏览它们并不难。
一个改进可能是不仅提供每个站点设置的描述，还提供文档链接。有时描述是不够的，只能在您已经知道的情况下作为提醒。话虽如此，搜索信息或在此处提问也足够容易了。
“30分钟安装”页面链接到精选的论坛主题。那可能是添加更多文档链接的最佳位置。
每个人都会有不同的关注点，很难满足所有人的需求。我来自 Mailman，所以觉得 Discourse 处理电子邮件的方式有点杂乱无章，但我意识到它已经足够好了，而且我没有遇到任何真正的问题。
如果您想要一个社区可编辑的猫数据库（我不确定这是否是您想要的确切内容），请尝试使用 MediaWiki 加上 Cargo（或 SMW）和 Page Forms。
4 个赞
同意。这将是一个大工程，但如果每个站点设置（或者至少是那些仅有简短描述不够用的设置）都能链接到一个文档页面部分，解释其功能以及如何与其他相关设置交互，那就太好了。
4 个赞
