跳到内容
SIAX.io

文档

SIAX Platform 入门指南

本页描述从您下单到服务上线之间会发生什么，以及您在每项产品中首先要做的具体操作。它是一份文档：命令、DNS 记录，以及第一天真正会遇到的错误，而不是一封欢迎词。 我们所运行的一切都是开源的——App Hosting 背后的 Coolify、Docker 与 Traefik，Managed Postgres 背后的 PostgreSQL 与 pgBackRest，对象存储的 Garage，备份的 restic，邮件的 Stalwart，Git 的 Gitea，DNS 的 PowerDNS，AI 网关的 LiteLLM。这对您意味着两点：您已经熟悉的工具开箱即可用，而且您可以随时将数据和配置迁往别处。凡是费力之处，我们都明确写出来，而不是轻描淡写。

01

从下单到登录

下单从产品页面开始。您在配置器中选择配置，看着价格更新，然后下单。价格总会在订单创建前于服务器上重新计算，因此结账时的金额就是实际计费金额。下单无需账户——一个邮箱地址即可；账户在付款后创建。

付款后您会收到两封邮件：一封是订单确认，说明您购买了什么、价格多少；另一封是创建账户的登录链接。该链接是单次使用，有效期很短。如果已过期或从未收到，请从登录页面重新请求，并先检查您的垃圾邮件文件夹——确认邮件落入那里的情况比您想象的更常见。

账户创建后，您订购的内容即被配置。大多数服务在您填完计费信息之前就已上线。例外是专属服务器：由于需要分配物理硬件，它会经过人工审核，您会收到带有计划交付日期的通知，而非一台现成的机器。

网站上的所有价格均不含增值税，除非另有说明，否则均按月计。域名按年计费。

  • App Hosting：一分钟内上线
  • VPS：2–3 分钟内就绪
  • Managed Postgres：一分钟内就绪
  • 对象存储、备份与监控：即时
  • 域名、邮件、Git 与 CI、AI 网关：数分钟
  • 专属服务器：1–3 个工作日，人工审核
02

控制台里的头一刻钟

在开始部署之前完成以下事项，以免在生产环境已有东西时再去补救。

立即设置密码并开启双因素认证。然后添加计费信息：组织编号、增值税注册号，以及一个送达财务部门而非个人邮箱的发票地址。至少添加一位具有管理员权限的同事——只有一个可访问的账户是运营风险，而非安全措施。

从一开始就将环境分开。为生产与测试创建独立的项目，而不是把所有东西放在一起，并按用途为资源命名。现在做对不花任何成本，日后拆解却很麻烦。

有意识地选择区域。我们的数据中心位于赫尔辛基、法尔肯施泰因与纽伦堡。应用、数据库与存储之间在同一区域内的延迟很低，跨区域则明显差异，所以请把彼此通信的东西放在一起。日后更改区域并不是一个设置——它意味着新资源外加数据迁移。

  • 每个具有管理员权限的账户都开启双因素认证
  • 两条联系渠道：一条用于发票，一条用于运营告警
  • 为生产与测试分别创建项目
  • 应用、数据库与存储使用同一区域
03

App Hosting：连接仓库、选择分支、部署

首先连接 Git 源。SIAX Git（Gitea）、GitHub 与 GitLab 均可；连接通过 OAuth 或部署密钥完成，后者可让您保持更窄的访问范围。然后选择仓库与分支。您指向的分支将成为生产分支——每一次推送到该分支都会构建并部署。

如果仓库中有 Dockerfile，则使用它。如果没有，构建步骤会尝试自动识别项目。自动识别适用于常见的 Node、Python 与 Go 项目，但您自己的 Dockerfile 能让您掌控构建步骤，也是我们对任何打算存活超过演示时间的东西的建议。

在首次部署前添加环境变量。密钥可以写入，但此后无法以明文读回，因此请自行保留一份副本。应用必须监听 0.0.0.0 以及 PORT 环境变量中的端口——在 localhost 上硬编码 3000 是构建成功却无响应的最常见原因。设置健康检查路径，避免损坏的版本接管流量。

自定义域名使用控制台所示的值进行指向。一旦 DNS 记录指向正确，TLS 证书即自动签发，这可能需要几分钟。在证书签发前，请不要在门前放置代理或 CDN——那会使验证失败。Pull request 拥有各自的预览环境，合并后即被清理，回滚到先前版本只需一次点击。

  • devDependencies 中的构建工具必须在构建时安装（npm ci --include=dev，或多阶段 Dockerfile）
  • 必须提交 lockfile，否则构建不可复现
  • 文件系统是易失的：上传与生成的文件应放入对象存储
  • 后台任务与队列应作为独立服务运行，而非与 Web 服务器同进程
  • 构建可能需要比生产运行时更多的内存——之后可以调整大小
04

VPS 与专属服务器：先放好密钥

在创建机器之前，在控制台中添加您的公共 SSH 密钥，最好是 ed25519 密钥。密码登录一开始就被禁用，因此密钥是唯一的进入方式。如果您在没有密钥的情况下创建机器，之后需要借助控制台访问来添加。

首次登录使用 ssh root@ 后接控制台中显示的 IP 地址。随即做好基础工作：更新软件包、创建带 sudo 的用户、禁用 SSH 的 root 登录、开启自动安全更新，并设置防火墙。只开放您实际使用的端口。如果防火墙规则把您锁在外面，控制台访问仍在——它不经过 SSH。

VPS 是一台拥有 root 权限的机器，而非受管理的平台。快照已包含，但计划备份是您在订购时选择的附加项（每日并保留七天历史，或每小时并保留三十天）。如果不选择备份，自行处理就是您的责任。如果您还要从机器上发送邮件，还需要为 IP 地址设置反向 DNS。

专属服务器的工作方式不同：我们安装并修补操作系统、监控机器，并运行经过验证的恢复的备份。交付时您会获得访问凭据，时间在订购后的 1–3 个工作日。

  • ssh-keygen -t ed25519，在配置前于控制台添加公钥
  • apt update && apt full-upgrade，然后创建带 sudo 的非 root 用户
  • 在 sshd_config 中设置 PermitRootLogin no 和 PasswordAuthentication no
  • 防火墙只开放服务所需的端口
  • SSH 不可达时使用浏览器控制台访问
05

Managed Postgres：连接串与迁移数据

控制台会提供主机、端口、数据库名、用户与密码，外加形如 postgres://user:password@host:5432/database?sslmode=require 的现成连接串。TLS 是强制性的；抱怨证书的客户端通常就是 CA 包过旧的客户端。数据库可在不公开暴露的情况下被您的其他 SIAX 资源访问——只有确实需要时才开放给公网，若要开放，请将其限制为已知地址。

您会获得两条连接串：一条池化，一条直连。为打开大量短连接的应用使用池化连接串，迁移、模式变更、pg_dump 与 pg_restore 使用直连串。诸如 prepared statements 与 LISTEN/NOTIFY 等依赖会话的事物应放在直连串上。

迁移数据：使用 pg_dump -Fc 从源数据库转储，再用 pg_restore --no-owner --no-privileges -j4 加载到新数据库。使用与 Postgres 17 匹配的客户端工具，否则转储会抱怨格式版本。开始前检查您使用的扩展——常见扩展都有，但如果您的应用依赖我们不运行的扩展，需要在迁移前解决，而不是迁移过程中。

对停机时间要现实。转储与恢复意味着写操作必须在过程中停止：几个 GB 需要几分钟，数百 GB 需要数小时，索引在恢复后重建。如果想要接近零停机，需要逻辑复制与计划好的切换，这是一项独立的工作，不是一个下午就能完成的。转储中不携带的内容——供应商特定的认证、绑定于平台自身用户表的行级策略、无服务器自动扩容设置、参数组——必须在之后重建。

  • pg_dump -Fc -d source -f dump.pgc
  • pg_restore --no-owner --no-privileges -j4 -d target-string dump.pgc
  • 恢复后、放行流量前运行 ANALYZE
  • 在切换 DNS 或连接串之前，对照源表逐表核实行数
  • 支持时点恢复，但在真正需要之前先在一份副本上测试恢复
06

对象存储与备份：S3 密钥、端点和 restic 仓库

在控制台中创建 bucket，然后生成访问密钥对。密钥只显示一次——请立即放入您的密钥管理器中。端点 URL 紧挨着密钥出现，是除密钥之外唯一需要在现有代码中更改的设置：API 兼容 S3，因此 AWS SDK、boto3、aws-cli、rclone 与 s3cmd 均原样可用。

两个细节通常会绊倒第一次尝试。设置 path-style 寻址（SDK 中的 forcePathStyle），而非 virtual-host style。并填写 region 字段，即使它在我们这边毫无意义——多个 SDK 没有值就拒绝启动。在应用里排查之前，先用 aws s3 ls --endpoint-url=... 验证。如果要从 S3 或 Blob Storage 迁移数据，带校验和的 rclone copy 是简单路径；预期公共 bucket 需要替换为签名 URL，因为两者 ACL 模型并不相同。出站流量最高为存储量的三倍，含在价格内。

备份产品即 plain restic，面向属于您自己的 rest-server 端点。使用 restic -r rest:https://... init 初始化仓库，设置仓库密码，并将其存放在被备份机器以外的地方。加密在您的端完成、数据离开机器之前进行，这也意味着丢失仓库密码会使备份无法读取——我们无法恢复它，而这正是这一设计的全部意义。

使用 systemd timer 或 cron 计划任务，按保留策略运行 restic forget --prune，并定期运行 restic check。恢复演练由我们这边按计划运行并带有日期记录，因此您有证据证明恢复确实有效，而非仅仅是任务启动了。

  • restic -r rest:https://endpoint/repo init
  • restic backup /path --verbose，密码放在只有 root 能读取的文件中
  • restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
  • restic restore latest --target /tmp/test —— 第一周内您自己也做一次这个演练
07

域名与邮件：必须正确的 DNS 记录

在 DNS 中四件事全部正确之前，邮件无法工作。控制台会显示您的域名的确切值；形态如下。

MX 指向控制台指定的主机，优先级 10，旧的 MX 记录应移除——而不是留着作后备。SPF 是域名根处的一条 TXT 记录，只能有一条：如果已有其他发件方（发票系统、时事通讯），请合并到同一条记录中。DKIM 按控制台显示的记录与选择器添加。DMARC 是 _dmarc 处的 TXT 记录，带报告地址。

迁移时顺序重要。先创建邮箱并让来自 Google Workspace 或 Microsoft 365 的迁移完成同步——这已包含在价格中，由我们代为完成。在切换前一天将 MX 记录的 TTL 降至 300 秒。最后再切换 MX。预计会有一段邮件同时落入两处的时期，因为解析器需要追赶；这是正常的，不是故障。

一个关于可达性的坦诚警告：一个从新基础设施开始发信的域名，在接收方提供商眼中还没有信誉记录。先用 p=none 运行 DMARC 几周，阅读报告，然后收紧到 p=quarantine，再到 p=reject。不要在第一天就发送大量邮件——那会留下一个需要数周才能弥补的糟糕开局。如果 DNS 托管在其他提供商处也可以，但传播与更改将属于他们，而非我们。

要将域名迁入我们这里，域名需在当前注册商处解锁，并且需要授权代码。.se 的转移通常约需五天。DNS 可在界面中管理，也可用 octoDNS 以代码方式管理，以便对区域进行版本控制。

  • MX：来自控制台的值，优先级 10，移除旧记录
  • SPF：根处一条 TXT 记录，包含所有合法发件方，以 -all 结尾
  • DKIM：控制台显示的记录与选择器，按域名
  • DMARC：_dmarc 处的 TXT，从 p=none 与您真正阅读的 rua 地址开始
  • 切换前 TTL 300，之后恢复正常
08

Git、CI、监控与 AI 网关

Git 导入会连同历史、issue 与 pull request 一并带来。您提供仓库 URL 与源访问令牌，如果希望在过渡期间保留旧位置作为只读副本，可以选择镜像。构建分钟数不计量——CI 在您的方案上运行。切换后，用 git remote set-url 更新远端，并重新指向 webhook 与部署流程。

对 CI 迁移要对自己诚实。简单的工作流程可由 act_runner 原样运行，但调用源平台自身 API 的步骤、假定该平台的 marketplace action，以及与第三方的 OIDC 联邦则必须重写。为一条正常的流水线预留半天到一天，如果它由大量现成 action 构建，时间还要更长。

监控只需几分钟即可启动：设置针对 URL、TCP 端口、证书与 cron 任务的检查，将告警连接到邮件、Slack、Telegram 或 webhook，并可选开启公共状态页面向客户展示状态。十次检查免费，无时间限制，也无需卡信息。

AI 网关暴露 OpenAI 兼容 API。为每个项目创建一把虚拟密钥、设置预算上限，并把客户端中的 base URL 重新指向——除此之外代码无需更改。供应商的密钥位于网关中而非应用里，而这正是关键：您可以在不触碰代码的情况下切换模型，并在追踪视图中看到每一次调用。如果您希望流量保持在欧盟境内，将其路由到我们自己集群上运行的模型，但请注意，开放模型在大模型最擅长的某些任务上并非直接替代品——在生产中切换前，请先用自己的评测进行测试。

  • 用令牌导入仓库，过渡期运行镜像
  • git remote set-url origin，更新 webhooks 与部署密钥
  • 包含 npm 与 Docker 的软件包注册表——重新指向 .npmrc 与 docker login
  • 监控：10 次检查免费，告警到 Slack 或 webhook
  • AI 网关：每个项目一把虚拟密钥与一个预算上限
09

第一天常见的坑，以及在哪里获得帮助

我们第一天收到的几乎所有工单都可归结为同样几件事，且大多数可以立即解决。在联系我们之前：检查 DNS 是否如您所想的指向（dig +short）、应用是否监听 0.0.0.0 与正确的端口，以及 SDK 是否已为对象存储设置了 region 与 path-style。

如果需要我们，控制台中每个资源上都有支持表单——从那里提交的工单会自动带上它涉及哪个资源，省下一轮提问。您也可以直接回复订单确认邮件。响应时间与承诺见 SLA 条款；此处不再重复，以免同一个承诺出现两个版本。平台事件会在状态页发布，而对于超过一个下午工作量的迁移，您可以将帮助作为一项委托订购，而不是独自硬撑。

有一件事值得在一开始就知道：SIAX 不持有 ISO 27001、SOC 2 或 PCI-DSS。我们拥有的是附数据处理协议的 GDPR 合规、所有数据均在欧盟境内，以及您可以审计并离开的开源技术栈。如果您的采购流程需要证书，我们今天不是合适的供应商，在迁移之前知道这一点比之后好。

  • 没有登录邮件：检查垃圾邮件，重新请求链接——旧链接单次使用且有效期短
  • 证书未签发：DNS 尚未正确指向，或验证期间有代理挡在前面
  • 构建成功后 502：应用监听 localhost 或硬编码端口，而非 PORT
  • Postgres 拒绝连接：缺少 sslmode，或您试图从外部访问却未为其开放
  • S3 调用失败：region 字段为空，或使用 virtual-host style 而非 path-style
  • 邮件落入垃圾箱：SPF、DKIM 与 DMARC 就绪，但域名尚无发送历史
10

常见问题

下单前需要创建账户吗？
不需要。结账采用访客结账——输入邮箱地址、付款，账户随后通过发送到同一地址的单次使用链接创建。链接有效期短。如已过期，请从登录页重新请求。
付款后服务多快上线？
App Hosting 一分钟内上线，VPS 2–3 分钟，Managed Postgres 一分钟内，对象存储、备份与监控即时。域名、邮件、Git 与 AI 网关需要几分钟。专属服务器因硬件需要分配而接受人工审核，耗时 1–3 个工作日。
之后可以更改大小或区域吗？
大小随时可改——CPU 与内存通过资源的短暂重启进行扩展，不移动数据。区域无法直接更改：在实践中意味着新资源外加数据迁移，以及随之而来的停机。因此购买时请慎重选择区域，并将应用、数据库与存储放在同一区域。
SIAX 是否持有 ISO 27001 或 SOC 2？
不。SIAX 既不持有 ISO 27001、SOC 2，也不持有 PCI-DSS。取而代之的是附数据处理协议的 GDPR 合规、数据驻留在欧盟境内（赫尔辛基、法尔肯施泰因、纽伦堡），不向第三国传输，且整个技术栈开源、因而可审计。如果您的采购流程需要证书，我们今天不是合适的供应商。
下单前我需要准备什么？
如果是 VPS 或专属服务器，需要一把公共 SSH 密钥；对将要使用的域名的 DNS 访问权；一个已提交 lockfile、最好还有 Dockerfile 的仓库（用于 App Hosting）；以及如果迁移数据库，一份新的转储。域名转移需要授权代码，且域名需在当前注册商处解锁。
你们能替我们做迁移吗？
来自 Google Workspace 或 Microsoft 365 的邮件迁移包含在邮件价格中——我们负责移动邮箱。来自 GitHub 的、带有历史、issue 与 pull request 的 Git 导入，是您自己在界面中几分钟内即可完成的事。数据库、存储与应用迁移因差异过大而无法包含；它们作为委托进行，您可以在下单时的备注字段或通过服务请求描述需求。
如果改变主意，我如何退出来？
数据全程使用标准格式：Postgres 用 pg_dump，对象存储用 S3 API，您已持有密钥的 restic 仓库，完整的 Git 历史，以及为应用准备的 compose 文件。域名可免费迁出。真正耗费时间的仍是粘合剂——CI 流程、webhooks、告警规则与 DNS 切换——无论数据有多可移植，都必须在下一家供应商处重建。