Misskey 2026.10.1 Docker Compose 部署指南

目标：在一台 Linux 主机上，用 Docker Compose 把 Misskey 2026.10.1 以官方预构建产物路线从零部署到「浏览器可打开、管理员可登录、API 可发贴」的可用状态。本文全部命令与回显均为 2026-11-02 实测记录，包括国内网络环境下获取 2.66GB 产物的完整排障链。认知与选型背景见《Misskey 2026.10.1 介绍与选型指南》，配置参数逐项解说见《Misskey 2026.10.1 配置参数详解》，日常运维命令见《Misskey 2026.10.1 常用 CLI 命令与工具详解》。

一、环境信息

本章为实测环境口径，供读者复核。

组件与版本：Misskey 2026.10.1（官方预构建产物 misskey/misskey:2026.10.1，产物 ID 99172b82d5db，实测大小 2.66GB；运行时自报版本 Misskey v2026.10.1，见 9.2 节）。
运行时：Node.js v26.12.1（产物 Dockerfile ARG NODE_VERSION=26.12.1-trixie，实测 node -v 回显一致）、PostgreSQL 18.6（postgres:18-alpine，实测 433MB）、Redis 7.4.12（redis:7-alpine，实测 57.8MB）。
编排：Docker Compose v2（docker compose 子命令形态），web/db/redis 三服务。
宿主：Linux x86_64；本实测宿主端口段将 8138 分配给 Misskey Web 入口（容器内固定监听 3000）。
重要事实（实测确证）：官方仓库根目录没有现成的 docker-compose.yml——直接访问该路径返回 404: Not Found（实测落盘原文如下）：
```
404: Not Found
```
官方安装文档（misskey-hub《Create Misskey instance with Docker Compose》）的 Docker 主线是源码构建路线：克隆仓库后 cp ./docker-compose.yml.example ./docker-compose.yml，再 docker compose build + docker compose run --rm web pnpm run init。仓库内示例编排 compose_example.yml 的应用服务同样写 build: .（源码构建），并非预构建产物。
本文路线：跳过源码构建，直接使用 Docker Hub 上带版本号的官方预构建产物 misskey/misskey:2026.10.1 编排部署（产物内含编译好的前后端，见第二章产物解剖）。两条路线的对比与取舍见 2.3 节。

二、部署架构总览

2.1 三服务拓扑

本文编排定义三个服务，职责如下：

服务名	使用的产物	角色	关键参数
`web`	`misskey/misskey:2026.10.1`（2.66GB 预构建产物）	Misskey 应用服务（Web + API + 联邦 + 作业队列）	`8138:3000`；`files`/`.config` bind 挂载；`depends_on` 健康条件
`db`	`postgres:18-alpine`（433MB）	PostgreSQL 18 数据服务	`env_file: .config/docker.env`；数据 bind 到 `./db`；`pg_isready` 健康检查
`redis`	`redis:7-alpine`（57.8MB）	队列/缓存/pubsub	数据 bind 到 `./redis`；`redis-cli ping` 健康检查

网络分两段：internal_network（internal: true，web↔db/redis 内部通信，db/redis 不出网）与 external_network（web 出站联邦/抓取用，实测子网 10.89.64.0/24）。

2.2 预构建产物解剖

产物 Dockerfile（官方仓库根目录 Dockerfile，实测拉取核对）的关键事实：

三阶段构建：native-builder（BUILDPLATFORM 编译 TS 与前端资源）→ target-builder（目标平台原生依赖）→ runner（node:26.12.1-trixie-slim 运行时）；
非特权运行：ARG UID="991" / ARG GID="991"，创建 misskey 用户（家目录 /misskey），USER misskey——宿主 files 目录必须对该 UID 可写（见第五章）；
jemalloc：LD_PRELOAD=/usr/local/lib/libjemalloc.so，Node 内存分配器换 jemalloc；
supervisor：ENTRYPOINT ["/usr/bin/tini", "--"]，CMD ["pnpm", "run", "migrateandstart"]——启动即自动先跑数据库迁移再拉起服务，无需像 Akkoma 那样手工分步 init；
健康检查：HEALTHCHECK CMD /bin/bash /misskey/healthcheck.sh（读 built/.config.json 取端口后 curl /healthz），与编排的 depends_on: condition: service_healthy 联动。

💡 技术拓展：容器化部署的产物获取方式不止「直接拉取」一种。常见路线对比——

路线特点适用
官方源直接拉取最简，依赖到 Docker Hub 的连通性境外/直连通畅环境
镜像加速站改写前缀改 image 前缀即可，但公共加速站普遍白名单化/限速加速站在白名单内时
代理 + skopeo 导出 tar 再导入绕开守护进程拉取链路，可控可重放拉取卡死、需离线分发
源码构建（官方主线）不依赖产物分发，但需要完整构建链与时间需要改源码/无预构建产物时

本文实测环境直连与加速站均不可用，最终走「代理 + skopeo」路线（第三章）。

路线	特点	适用
官方源直接拉取	最简，依赖到 Docker Hub 的连通性	境外/直连通畅环境
镜像加速站改写前缀	改 image 前缀即可，但公共加速站普遍白名单化/限速	加速站在白名单内时
代理 + skopeo 导出 tar 再导入	绕开守护进程拉取链路，可控可重放	拉取卡死、需离线分发
源码构建（官方主线）	不依赖产物分发，但需要完整构建链与时间	需要改源码/无预构建产物时

2.3 与官方源码构建路线的对比

维度	官方源码构建（compose_example.yml）	本文预构建产物路线
应用服务 image	`build: .`（本地构建）	`misskey/misskey:2026.10.1`（直接引用）
初始化	需手工 `docker compose run --rm web pnpm run init`	首启自动 `migrateandstart`
升级	git pull + 重新 build	换 image 标签重启
依赖	需要源码树 + 构建链	只需产物 + 配置目录
版本锚定	跟随 master 分支	精确锁定 2026.10.1

Misskey 官方在 Docker Hub 发布带版本号产物（与 Akkoma「产物通道停滞、只能源码构建」相反，见《Akkoma 3.20.1 介绍与选型指南》第一章的产物实查结论），因此预构建路线是本文首选。

三、获取预构建产物（排障实录）

产物 2.66GB，直连 Docker Hub 不可达，本章完整记录四条获取路线的实测结果。

路线 1：镜像加速站 daocloud——改写 image 前缀后拉取，被加速站白名单拒绝，未进入传输阶段。

路线 2：加速站 docker.1ms.run——改前缀拉取，守护进程直接报找不到该产物：

Error response from daemon: No such image: docker.1ms.run/misskey/misskey:2026.10.1

路线 3：加速站 rat.dev + 直连改写——进入传输后卡死：唯一未命中的大层 82bfd61095f0 停在 4.194MB 不再增长，回显反复刷同一行（实测日志尾部节选）：

 82bfd61095f0 Downloading 4.194MB
 82bfd61095f0 Downloading 4.194MB
 82bfd61095f0 Downloading 4.194MB

其余 19 个层全部 Already exists/Pull complete（本机已有 node:26.12.1-trixie-slim 基础层），只有应用主层拉不动。

路线 4（最终成功）：HTTPS 代理 + skopeo 导出 tar + 导入：

HTTPS_PROXY=http://192.168.1.72:7897 skopeo copy --override-os linux --override-arch amd64 \
  docker://docker.io/misskey/misskey:2026.10.1 \
  docker-archive:/opt/data/quzuo/tmp/misskey/misskey-2026.10.1.tar:misskey/misskey:2026.10.1

实测回显（节选，20 个 blob 逐一复制）：

Getting image source signatures
Copying blob sha256:f2be67225471500c788ce88c597eb5ea8336e912ad1ca4815650e0281afe2034
Copying blob sha256:7b7c093ca38b87d30720821adabd2302b40a7c6ddab0fa831a98fc0845bcf74d
...
Copying config sha256:e0f9aeda9c320d0892404b168f9778970298a1ebb1901a4f2524a050107b3087
Writing manifest to image destination
SKOPEO_RC=0

导出 tar 实测 1830946304 字节（约 1.83GB），随后导入：

docker load -i /opt/data/quzuo/tmp/misskey/misskey-2026.10.1.tar

验证产物就位（docker images 实测行）：

misskey/misskey:2026.10.1   99172b82d5db   2.66GB
postgres:18-alpine          10a5c69a8303   433MB
redis:7-alpine              8da19c7399dc   57.8MB

⚠️ 要点：skopeo copy 必须带 --override-os linux --override-arch amd64——skopeo 的 docker:// 源在代理链路上不保证 manifest 协商成功，显式钉住目标平台可绕过；docker load 后 image 名与标签即 misskey/misskey:2026.10.1，编排文件可直接引用。

四、编排文件

部署目录 ~/misskey/（实测为 /opt/data/quzuo/tmp/misskey/misskey/）下自建 docker-compose.yml。以官方 compose_example.yml 为底本，仅把 web 服务的 build: . 换成预构建产物引用，并补 container_name/端口/健康依赖：

name: misskey

services:
  web:
    image: misskey/misskey:2026.10.1
    container_name: misskey-web
    restart: always
    links:
      - db
      - redis
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
      - "8138:3000"
    networks:
      - internal_network
      - external_network
    volumes:
      - ./files:/misskey/files
      - ./.config:/misskey/.config:ro

  redis:
    container_name: misskey-redis
    restart: always
    image: redis:7-alpine
    networks:
      - internal_network
    volumes:
      - ./redis:/data
    healthcheck:
      test: "redis-cli ping"
      interval: 5s
      retries: 20

  db:
    container_name: misskey-db
    restart: always
    image: postgres:18-alpine
    networks:
      - internal_network
    env_file:
      - .config/docker.env
    volumes:
      - ./db:/var/lib/postgresql
    healthcheck:
      test: "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"
      interval: 5s
      retries: 20

networks:
  internal_network:
    internal: true
  external_network:
    ipam:
      config:
        - subnet: 10.89.64.0/24

要点解读：

image: misskey/misskey:2026.10.1 精确锁版本，不用 latest——Misskey 是 CalVer 高频发版（12 个月 18 个稳定版，见《Misskey 2026.10.1 介绍与选型指南》第一章），latest 漂移会连带触发不可控的数据库迁移。
db/redis 只挂 internal_network 且该网络 internal: true——数据服务不出网，仅 web 双网可出站；
depends_on 用健康条件：web 必须等 db/redis healthy 才启动，首启迁移不会打空（实测回显见 9.1 节的 Waiting/Healthy 序列）；
.config 只读挂载（:ro）：产物内 compile-config 把 YAML 编译到容器内 built/.config.json，不回写配置目录；
pg_isready 测试里的 $$ 是 Compose 的转义写法，让变量在容器内 shell 展开而非宿主。

五、目录与属主准备

产物内应用以 UID/GID 991 运行（Dockerfile 实测），附件目录 ./files 必须对该属主可写，否则上传/头像落盘失败：

mkdir -p ~/misskey/{files,db,redis,.config}
chown -R 991:991 ~/misskey/files

实测验证（ls -ln 只看数字属主）：

total 0

（files 目录属主已置为 991:991，空目录 total 0；首启后头像、附件即落在此目录，见 12.4 节。）

⚠️ 要点：db/redis 目录不要chown 991——postgres/redis 官方产物以各自默认用户运行并会在首次启动时自行初始化数据目录属主；把 ./db 交给非默认 UID 反而会导致 PG 拒绝启动。

六、配置文件 default.yml

从官方 .config/docker_example.yml（仓库 .config 目录）复制为 default.yml，改动最小集如下（实测部署所用文件的关键行）：

url: http://127.0.0.1:8138/
port: 3000

db:
  host: db
  port: 5432
  db: misskey
  user: misskey
  pass: q1w2e3r4

dbReplications: false

redis:
  host: redis
  port: 6379

fulltextSearch:
  provider: sqlLike

id: 'aidx'

proxyBypassHosts:
  - api.deepl.com
  - api-free.deepl.com
  - www.recaptcha.net
  - hcaptcha.com
  - challenges.cloudflare.com

maxFileSize: 104857600

逐项说明（完整参数体系见《Misskey 2026.10.1 配置参数详解》）：

url：实例对外 URL，一旦启动不可更改（模板原文 "ONCE YOU HAVE STARTED THE INSTANCE, DO NOT CHANGE THE URL SETTINGS AFTER THAT!"）；本地实测用 http://127.0.0.1:8138/，生产必须换成 HTTPS 域名并前置反向代理（模板明确 Misskey 需反代支持 HTTPS）；
port: 3000：容器内监听端口，与编排 8138:3000 映射对应；
db.*：必须与 docker.env 里 POSTGRES_* 建的库/用户/口令一致（实测 misskey/q1w2e3r4）；
redis.host: redis：走编排服务名；
fulltextSearch.provider: sqlLike：默认值，零扩展依赖（可选 pgroonga/meilisearch，见选型篇 3.4 节）；
id: 'aidx'：ID 生成方式，同为一次定型项；实测产物内对象 ID 形如 at2j3aq0wb6e0003；
maxFileSize: 104857600：上传统一下限 100MiB（模板默认 250MiB=262144000，实测调小以做生效验证，见 12.2 节与配置篇）。

七、环境变量 docker.env

db 服务通过 env_file: .config/docker.env 注入 PostgreSQL 初始化变量（实测文件全文）：

# misskey settings
# MISSKEY_URL=http://127.0.0.1:8138/

# db settings
POSTGRES_PASSWORD=q1w2e3r4
POSTGRES_USER=misskey
POSTGRES_DB=misskey
DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}"

POSTGRES_* 三件套让 postgres:18-alpine 首启自动建库建用户（口令与 default.yml 的 db.pass 必须一致，实测均为 q1w2e3r4）；
注释掉的 MISSKEY_URL 是产物支持的环境变量兜底：后端 loadConfig 实测支持 MISSKEY_URL、DATABASE_DB/USER/PASSWORD、PORT、MISSKEY_CONFIG_YML、MISSKEY_MIGRATION_CREATE_INDEX_CONCURRENTLY 等 env 覆盖（来源：产物内 packages/backend/built/config.js 与 ormconfig.js 源码核对），YAML 里留空时自动回退 env。

八、启动前检查清单

检查项	命令	实测结果
三产物就位	`docker images`	2.66GB / 433MB / 57.8MB 三行齐（见第三章）
编排语法	`docker compose config -q`	无输出即通过
端口空闲	`ss -ltnp	grep 8138`
files 属主	`ls -ln files`	991:991
配置一致	`grep pass: .config/default.yml` 与 `grep PASSWORD .config/docker.env`	同为 `q1w2e3r4`

九、首次启动与初始化

9.1 拉起

docker compose up -d

实测回显（完整）：

 Network misskey_external_network Creating 
 Network misskey_external_network Creating 
 Network misskey_internal_network Creating 
 Network misskey_internal_network Creating 
 Network misskey_external_network Created 
 Network misskey_external_network Created 
 Network misskey_internal_network Created 
 Network misskey_internal_network Created 
 Container misskey-db Creating 
 Container misskey-redis Creating 
 Container misskey-redis Created 
 Container misskey-db Created 
 Container misskey-web Creating 
 Container misskey-web Created 
 Container misskey-db Starting 
 Container misskey-redis Starting 
 Container misskey-db Started 
 Container misskey-redis Started 
 Container misskey-redis Waiting 
 Container misskey-db Waiting 
 Container misskey-db Healthy 
 Container misskey-redis Healthy 
 Container misskey-web Starting 
 Container misskey-web Started

注意 Waiting → Healthy 四行：depends_on 健康条件生效，web 在 db/redis 双双 healthy 后才启动。

9.2 首启自动迁移

web 容器 CMD pnpm run migrateandstart 先编译配置再跑迁移（实测日志节选）：

$ pnpm compile-config && pnpm typeorm migration:run -d ormconfig.js
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = $1 AND "table_name" = $2 -- PARAMETERS: ["public","migrations"]
query: CREATE TABLE "migrations" ("id" SERIAL NOT NULL, "timestamp" bigint NOT NULL, "name" character varying NOT NULL, CONSTRAINT "PK_8c82d7f526340ab734260ea46be" PRIMARY KEY ("id"))
query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC
0 migrations are already loaded in the database.
349 migrations were found in the source code.
349 migrations are new migrations must be executed.
query: INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1000000000000,"Init1000000000000"]
query: INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1556348509290,"Pages1556348509290"]

349 个迁移全部执行完后，应用进程拉起（实测日志）：

INFO *	[core boot]	Misskey v2026.10.1
INFO *	[core nest]	NestFactory: Starting Nest application...
INFO *	[core boot]	Starting 1 worker...
INFO 1	[core]	Start worker process... pid: 212
DONE *	[core boot]	All workers started
DONE *	[core boot]	Now listening on port 3000 on http://127.0.0.1:8138

Starting 1 worker... 即默认 clusterLimit 未设时的单 worker 模型（改为 2 后的对照回显见《Misskey 2026.10.1 配置参数详解》）。

9.3 初始化验证

docker exec misskey-db psql -U misskey -d misskey -tAc \
  "select count(*) from pg_tables where schemaname='public';"

docker exec misskey-db psql -U misskey -d misskey -tAc "select count(*) from migrations;"

docker exec misskey-redis redis-cli info server | head -6

# Server
redis_version:7.4.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:a3bb3c7b72c4210a
redis_mode:standalone

117 张业务表、349 条迁移记录、standalone Redis 7.4.12——初始化闭环确认。

十、健康检查与 Web 验证

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8138/healthz

curl -sI http://127.0.0.1:8138/

实测回显（节选）：

HTTP/1.1 200 OK
x-frame-options: DENY
cache-control: public, max-age=30
content-type: text/html; charset=utf-8
content-length: 16161
Date: Mon, 02 Nov 2026 08:32:16 GMT
Connection: keep-alive
Keep-Alive: timeout=72

首页 200、16161 字节的 SPA 壳页面即前端产物正常。服务状态（docker compose ps 实测）：

NAME            IMAGE                       COMMAND                  SERVICE   CREATED          STATUS                    PORTS
misskey-db      postgres:18-alpine          "docker-entrypoint.s…"   db        51 seconds ago   Up 51 seconds (healthy)   5432/tcp
misskey-redis   redis:7-alpine              "docker-entrypoint.s…"   redis     51 seconds ago   Up 50 seconds (healthy)   6379/tcp
misskey-web     misskey/misskey:2026.10.1   "/usr/bin/tini -- pn…"   web       51 seconds ago   Up 45 seconds (healthy)   0.0.0.0:8138->3000/tcp, [::]:8138->3000/tcp

三个服务全部 (healthy)：web 的 healthcheck 走产物内 healthcheck.sh（读 built/.config.json 的端口再 curl /healthz），与编排层健康条件形成双保险。

十一、引导首个管理员账号

全新空实例没有任何用户，而 Misskey 默认 disableRegistration: true（实测 /api/meta 回显，见 12.1 节）——注册入口是关的。官方为此提供了空实例引导通道：当 meta.rootUserId == null 时，/api/admin/accounts/create 可免认证创建首个管理员。实测：

curl -s -X POST http://127.0.0.1:8138/api/admin/accounts/create \
  -H 'Content-Type: application/json' \
  -d '{"username":"root","password":"q1w2e3r4"}'

返回新建账号对象，实测拿到 id=at2j3aq0wb6e0003、API token lTWbYiUooUCjelCZ、isAdmin=true。该通道只在「实例还没有任何管理员」时开放，创建后即关闭。

口令登录验证（/api/signin-flow，实测回显）：

curl -s -X POST http://127.0.0.1:8138/api/signin-flow \
  -H 'Content-Type: application/json' \
  -d '{"username":"root","password":"q1w2e3r4"}'

{"finished":true,"id":"at2j3aq0wb6e0003","i":"lTWbYiUooUCjelCZ"}
HTTP=200

⚠️ 排障实录：错误的登录端点与限流。旧版登录端点 /api/signin 实测已移除（请求返回 404，access 日志实录 POST - 404）；错口令走 /api/signin-flow 返回 403：
{"error":{"id":"932c904e-9460-45b7-9ce6-7ed33be7eb2c"}}
HTTP=403
连续失败后触发按 IP 的登录限流，此后即使口令正确也返回 429：
{"error":{"message":"Too many failed attempts to sign in. Try again later.","code":"TOO_MANY_AUTHENTICATION_FAILURES","id":"22d05606-fbcf-421a-a2db-b32610dcfd1b"}}
HTTP=429
限流状态存在 Redis（实测键 127.0.0.1:8138:limit:ip-2vdb0h:signin:min，按分钟窗口），等待窗口过期后重试即恢复 200。

十二、部署后功能验证（API 与数据闭环）

12.1 实例元数据

Misskey 的 API 一律 POST，GET /api/meta 实测返回 405：

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8138/api/meta

curl -s -X POST http://127.0.0.1:8138/api/meta -H 'Content-Type: application/json' -d '{}'

实测回显（关键节选）：

{"version": "2026.10.1", "uri": "http://127.0.0.1:8138", "maxFileSize": 104857600, "maxNoteTextLength": 3000, "disableRegistration": true}

version 与本文基准版一致；maxFileSize 正是 default.yml 里设置的 104857600（配置生效实证，更多生效实测见《Misskey 2026.10.1 配置参数详解》）。

12.2 发贴闭环

curl -s -X POST http://127.0.0.1:8138/api/notes/create \
  -H 'Content-Type: application/json' \
  -d '{"i":"lTWbYiUooUCjelCZ","text":"Misskey 2026.10.1 deploy verified via API"}'

实测回显（节选）：

{"createdNote":{"id":"at2kj3wqcfdt0003","createdAt":"2026-11-02T08:35:44.906Z","userId":"at2j3aq0wb6e0003","user":{"username":"root","host":null,...},"text":"Misskey 2026.10.1 deploy verified via API","visibility":"public","renoteCount":0,"repliesCount":0,"reactionCount":0,"fileIds":[],"files":[]}}

（输出节选，实测首尾；中间 user 子对象字段略。）

12.3 数据库落盘核对

docker exec misskey-db psql -U misskey -d misskey -tAc "select count(*) from note;"

⚠️ 实测细节：表名 user 是 PostgreSQL 保留字，查询必须写 "user" 带引号（不带引号实测报 ERROR: column "id" does not exist——被解析成系统视图）；管理员标记也不在 "user" 表列里（实测 role/role_assignment 表为空，本地管理员走 API 层，POST /api/i 回显 "isAdmin": true, "isModerator": true）。

12.4 附件目录验证

默认头像不落盘：实测 GET /identicon/root@127.0.0.1:8138 返回 200、1817 字节（即时生成），./files 目录保持 total 0 且属主 991:991——只有真正的附件上传才会写入该 bind 目录，属主校准（第五章）是后续上传可用的前提。

十三、重启与数据持久化验证

docker compose down
docker compose up -d

重建后 web 日志实测（节选）：

query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC
No migrations are pending
INFO *	[core boot]	Misskey v2026.10.1
INFO *	[core boot]	Starting 2 workers...
DONE *	[core boot]	Now listening on port 3000 on http://127.0.0.1:8138

No migrations are pending 证明迁移幂等、migrateandstart 可放心重复执行；note count 重建后仍为 2，数据全部存活（bind 挂载 ./db、./redis、./files）。

十四、更新流程

预构建产物路线的升级序列（与首启同构）：

# 1. 通读 CHANGELOG（官方安装文档 warning 原文要求）
# 2. 获取新版本产物（第三章任一路线，如 skopeo+代理导出后 docker load）
# 3. 换标签重启
sed -i 's|misskey/misskey:2026.10.1|misskey/misskey:<新版本>|' docker-compose.yml
docker compose up -d   # 重建 web，启动时自动跑增量迁移

⚠️ 要点：升级前务必备份 ./db 与 ./files——TypeORM 迁移随版本追加（实测 349 个迁移文件），不可回滚；url 与 id 两项配置在新版本同样禁止改动。

十五、排障实录汇总

#	现象	根因	处置
1	仓库根目录找不到 `docker-compose.yml`（404）	官方主线示例是 `compose_example.yml` 且为源码构建	自建编排引用预构建产物（第四章）
2	daocloud 加速站拉取被拒	公共加速站白名单化	换路线
3	`docker.1ms.run/misskey/...` 报 `No such image`	该加速站未缓存此产物	换路线
4	拉取卡死：`82bfd61095f0 Downloading 4.194MB` 反复不涨	加速链路对大层限速/中断	`HTTPS_PROXY` + `skopeo copy --override-os/arch` 导出 tar + `docker load`
5	上传/头像失败风险（预防性）	产物以 UID/GID 991 运行	`chown -R 991:991 files`；`db`/`redis` 目录不要动属主
6	`GET /api/meta` 返回 405	Misskey API 一律 POST	`POST /api/meta -d '{}'`
7	`/api/signin` 404	旧登录端点已移除	改用 `/api/signin-flow`
8	正确口令登录返回 429 `TOO_MANY_AUTHENTICATION_FAILURES`	错口令触发按 IP 分钟级限流（Redis 键 `limit:ip-*:signin:min`）	等待窗口过期重试
9	`select ... from user` 报 `column "id" does not exist`	`user` 是 PG 保留字	写 `"user"`
10	web 容器反复重启、日志见连接错误	首启时 db 尚未 ready	编排已用 `depends_on` 健康条件规避；若仍出现，检查 `docker.env` 与 `default.yml` 凭据是否一致

十六、小结与关联

Misskey 官方 Docker 路线在 2026.10.1 呈现「文档写源码构建、制品有预构建产物」的双轨状态：预构建产物 + 三服务编排可以把部署压缩到「产物就位 → 两份配置 → up -d」三步，首启自动迁移（349 迁移/117 表）、自动健康检查、空实例免认证引导管理员，运维面比 Akkoma 的手工 init 序列小得多；代价是 2.66GB 产物与 PostgreSQL+Redis 双依赖的资源基线，以及 url/id 一次定型的纪律要求。

选型与架构背景：《Misskey 2026.10.1 介绍与选型指南》
配置参数逐项详解与生效实测：《Misskey 2026.10.1 配置参数详解》
CLI 与运维命令取证：《Misskey 2026.10.1 常用 CLI 命令与工具详解》

参考链接

官方仓库：https://github.com/misskey-dev/misskey（Dockerfile、compose_example.yml、.config/docker_example.yml、.config/docker_example.env）
官方 Docker 安装文档：https://misskey-hub.net/docs/for-admin/install/guides/docker/
预构建产物：https://hub.docker.com/r/misskey/misskey/tags
CHANGELOG：https://github.com/misskey-dev/misskey/blob/master/CHANGELOG.md
skopeo：https://github.com/containers/skopeo
PostgreSQL 官方镜像：https://hub.docker.com/_/postgres；Redis 官方镜像：https://hub.docker.com/_/redis