OpenDeploy Config 是 OpenDeploy 生态中的配置类工具，用于检查或补丁式修改某个服务的配置项，涵盖构建命令、启动命令、根目录、Dockerfile 路径、builder、端口、资源、健康检查等。直接调用时需先做全局 CLI 版本检查：npm list -g @opendeploydev/cli --depth=0 --json、npm view @opendeploydev/cli version --json、opendeploy preflight . --json；若全局版本落后于 npm 最新版则转交 opendeploy-setup，用户选择跳过更新时仅在已装全局 CLI 支持所需命令的前提下继续，此后不要再单独运行 --version、jq 或原始 curl 插件探测。
读取配置使用：opendeploy services config get <service-id> --json。补丁应尽量窄化，例如：opendeploy services config patch <service-id> --port 2368 --json；--build-command "pnpm build"；--start-command "pnpm start"；--root-directory "./apps/web"；--dockerfile-path "./Dockerfile"。补丁后需回读配置，再判断是否需要重启或重新部署；优先窄补丁而非重建服务。端口排查类问题转交 opendeploy-debug。
Dockerfile 模式可靠性规则：项目已有源码根目录 Dockerfile 时使用 Dockerfile 模式；若无 Dockerfile 且 OpenDeploy 自动检测无法生成可运行服务，可在获得明确的结构化源文件编辑批准后编写 Dockerfile——这属于正常路径而非失败，应先用仓库证据展示要新增的文件，再写入最小化的源码根 Dockerfile 和 .dockerignore。首次部署不要把 dockerfile_path 设为 Dockerfile.opendeploy；若仓库只有嵌套 Dockerfile（如 docker/Dockerfile），修改源根或复制重命名前须先询问用户。回读配置是必要但不充分的，下一次构建日志必须显示为 Dockerfile 模式而非 Railpack/自动检测。生成的 Dockerfile 应避免密钥、避免大范围改写应用、在框架支持时遵循 $PORT 并 EXPOSE HTTP 监听端口。
端口与持久化规则：Dockerfile 或 compose 暴露多个端口时，应把服务补丁到 HTTP 监听端口，不要为 OpenDeploy HTTP 入口选择 SSH/SMTP/原始 TCP 端口。若应用声明持久化数据路径而 OpenDeploy 未暴露存储/卷路由，应先询问存储策略再继续。除非存在管理员/引导计划或用户明确批准，不要设置安装锁或 setup 完成标志。资料未提供收费、平台与效果信息。