[!abstract] 选择原则 先问数据丢失和停机是否可接受，再问软件是否支持 ARM64，最后才看 CPU 和内存够不够。免费资源适合学习与可重建服务，不应成为重要数据的唯一归宿。

OCI 免费服务器负载选择

共同决策模型

业务价值
  -> 数据是否可恢复
  -> 软件是否支持 ARM64
  -> 是否需要公网端口
  -> 资源与流量是否在免费边界内
  -> 是否有人持续维护

适合的负载

场景	为什么适合	必须补齐的能力
静态网站/个人博客	资源消耗低、容易重建	HTTPS、备份、域名
轻量 API/机器人	容器化后易部署	限流、日志、健康检查
Linux/Docker 学习机	失败成本低	SSH 恢复路径、快照
Uptime/指标监控	有真实持续使用	告警外送、不要自监控唯一副本
定时任务	不需低延迟交互	幂等、日志、失败通知
开源个人工具	社区镜像丰富	ARM64 镜像、认证、备份

谨慎使用

数据库

可以用于练习或非关键小数据，但必须：

• 不公开数据库端口；
• 定期导出到异地；
• 记录恢复命令并实际演练；
• 控制磁盘增长和日志保留。

个人网盘与照片

免费块存储不是备份。只有在另有本地和异地副本时，才适合作为同步节点或缓存。

CI Runner 与构建

ARM64 可用于多架构验证，但构建负载可能突然占满 CPU、磁盘和网络。给缓存设置上限，避免把敏感仓库 token 长期留在公共实例。

网络代理

需要遵守服务条款和当地法律。代理节点具有高带宽、被滥用、凭据泄露和封禁风险；不能把端口全开或直接运行来源不明的一键脚本。

不适合的负载

• 唯一副本的密码库、照片、论文或生产数据库；
• 无法在 ARM64 运行且没有多架构镜像的软件；
• 需要稳定 SLA、固定高带宽或低抖动的商业服务；
• 需要 GPU、专用硬件或内核模块的任务；
• 无人维护、无人查看账单和告警的长期公网服务。

ARM64 兼容性检查

在 A1 上先确认：

uname -m
dpkg --print-architecture 2>/dev/null || rpm --eval '%{_arch}'

预期通常是 aarch64 或 arm64。Docker 镜像检查：

docker buildx imagetools inspect IMAGE:TAG

应看到 linux/arm64 manifest。只提供 linux/amd64 的镜像可能无法启动，或需要性能较差且不稳定的模拟。

最小部署成熟度

一个值得长期运行的服务至少应具备：

• 明确的配置文件和版本；
• 自动重启策略与健康检查；
• HTTPS 和身份认证；
• 不直接公开内部管理端口；
• 日志轮转和磁盘上限；
• 数据、配置和密钥分离；
• 可执行的备份与恢复步骤；
• 成本、流量和可用性告警。

推荐学习顺序

1. 先部署无状态测试页：在 OCI 部署第一个容器化服务。
2. 学习 Docker MOC 和 [[caddy|Caddy]]。
3. 再从 VPS 资源与综合应用 MOC 选择真实负载。
4. 上线前完成 维护与备份 OCI 服务器。

Related notes

• 所属 MOC：甲骨文云服务器 MOC
• 费用边界：OCI 免费额度与计费边界
• 部署：在 OCI 部署第一个容器化服务
• 备份：数据备份 MOC