Личный облачный Obsidian на CouchDB: кейс с Self‑hosted LiveSync, Caddy и Cloudflare

В этом кейсе мы пройдем путь к полностью самостоятельной синхронизации: плагин Self‑hosted LiveSync в связке с CouchDB, проксируемый через Caddy и управляемый Cloudflare для автоматических сертификатов и удобного DNS. На выходе — ваше «облако» для заметок, где вы контролируете все: от хранения и шифрования до резервных копий и отказоустойчивости.

Обсидиан — это не просто редактор Markdown, а гибкий рабочий стол для мыслей и базы знаний, где файлы остаются у вас. Но как только вы хотите использовать одну и ту же базу заметок на ноутбуке, десктопе и мобильном, встает вопрос синхронизации. Официальная синхронизация решает задачу, но не всем подходит по моделям доверия и контроля над данными.

Статья собрана по мотивам реального разворачивания и эксплуатации, включает пошаговую инструкцию, пояснения «почему так», рекомендации по безопасности, производительности, мобильной работе, многоуровневому резервированию и устранению неполадок. Даже если вы не админ со стажем, благодаря Docker и готовым конфигам вы сможете повторить решение за вечер. А если вы давно искали повод навести порядок в собственном «облаке», это идеальный старт.

TL;DR

Self‑hosted LiveSync для Obsidian — плагин, который синхронизирует заметки через ваш сервер CouchDB. Контроль над хранилищем и приватность остаются у вас.
Архитектура: CouchDB в Docker без прямой публикации наружу; Caddy как обратный прокси с TLS и DNS‑проверкой через Cloudflare; строгий CORS под Obsidian.
Минимальный стек: Docker Compose, CouchDB, кастомный Caddy (с плагином Cloudflare через xcaddy), один конфиг Caddyfile, .env с секретами и доменом.
Безопасность: TLS, бэкенд недоступен напрямую, CORS «только для Obsidian», обязательный админ в CouchDB, опционально end‑to‑end шифрование на уровне плагина (шифруются и имена файлов).
Процесс: подняли стек, проверили доступ, включили плагин Self‑hosted LiveSync, прошли мастер настройки, включили E2EE, выбрали пресет LiveSync, синхронизация пошла.
Производительность: исключайте «мусорные» папки, внимательно к вложениям, подумайте о компакции БД и регулярных бэкапах, следите за временем на сервере и сертификатами.
Траблшутинг: ошибки имени/резолвинга, CORS, 401, 403, сертификаты, конфликты при массовом переносе — разбор в отдельном разделе.
Кому подходит: тем, кто ценит контроль и приватность больше «поставил‑забыл»; кому важна масштабируемость и независимость от внешних сервисов; кто не боится Docker.

Что такое Obsidian и почему локальные заметки — это плюс и минус одновременно

Локальные файлы, приватность и контроль

Обсидиан хранит заметки в виде обычных файлов Markdown в вашем хранилище. Это простота, переносимость и отсутствие привязки к чужим серверам. Вы сами выбираете где лежит хранилище: в домашней папке, на отдельном диске, на сервере. Никакой магии — только понятные папки и файлы.

Проблема: синхронизация между устройствами

Как только у вас появляется второй компьютер или мобильный, возникает задача синхронизации. Простое «скинуть папку в облако» работает ровно до первых конфликтов и повреждений метаданных. Obsidian активно изменяет множество мелких файлов и технических JSON; классические «облака» с блокировками и медленным слежением за изменениями к этому не приспособлены.

Обзор способов синхронизации хранилища Obsidian

Официальная синхронизация

Решает проблему «из коробки» и стоит недорого. Но цена — доверие к стороннему сервису и отсутствие полного контроля над местом хранения. Если для вас это нормально, вариант достойный. Если же нет — ищем альтернативы.

Облачные папки (диск провайдера)

Просто, но рискованно: конфликты, отсутствие блокировок, неочевидные коллизии метаданных приводят к непредсказуемым результатам. Подойдет только для самых простых кейсов без активной работы на нескольких устройствах.

Плагин Git для Obsidian

Git отлично решает коллизии, позволяет «чекпоинтить» состояние и откатываться. Но конфликты все равно будут, и разруливать их придется вручную. Для разработчика это привычно, для автора заметок — отвлекает от сути.

Self‑hosted LiveSync + CouchDB

Золотая середина для тех, кто хочет контроль, но при этом — действительно «живую» синхронизацию. Плагин Self‑hosted LiveSync (ранее известный как Obsidian LiveSync) использует синхронизацию документ‑ориентированного хранилища, а CouchDB обеспечивает надежную репликацию, журналирование и устойчивость к конфликтам. Вы добавляете удобный прокси‑слой (Caddy) и автоматический TLS через DNS‑проверку у Cloudflare — и получаете собственный «облако‑сервис» синхронизации, но полностью на своей инфраструктуре.

Как это работает под капотом (кратко и по делу)

Плагин на стороне клиента хранит данные в локальной базе и синхронизирует их с CouchDB через репликацию.
Конфликты решаются механизмами, присущими документ‑ориентированным БД; плагин умеет минимизировать вероятность «лопнувших» конфликтов и автоматически их разруливать в простых случаях.
Можно включить сквозное шифрование: тогда контент и даже имена файлов покидают устройство в зашифрованном виде.
Сеть нестабильна? Репликация переживет офлайн, а затем догонит изменения при восстановлении соединения.

Архитектура решения: CouchDB за Caddy с TLS и DNS‑проверкой

Мы не публикуем CouchDB напрямую в интернет. Вместо этого весь входящий трафик принимает Caddy на выбранном порту, завершая TLS и проксируя запросы к контейнеру CouchDB по внутренней сети Docker. Так безопаснее и гибче: можно навесить заголовки CORS, тонко управлять сертификатами и маршрутизацией, а конфигурацию держать в одном обозримом файле.

Почему именно DNS‑проверка и Cloudflare

Автовыдача сертификатов работает даже для нестандартных портов, когда у вас нет классического 80/443 или нет возможности пробросить их.
DNS‑проверка не требует открытого входящего порта для валидации. Это полезно при ограничениях сети или при сложной схеме NAT.
Cloudflare удобен как DNS‑провайдер, а Caddy с плагином cloudflare упрощает весь процесс до пары строк конфигурации.

Про CORS и Obsidian

Обсидиан работает в оболочке, основанной на браузере. Чтобы приложение смогло обращаться к CouchDB, нужно корректно настроить заголовки CORS и явно разрешить происхождение приложения. Для Obsidian используется специальная схема происхождения, а предзапросы OPTIONS следует обрабатывать быстро и корректно.

Предварительные требования

Сервер: VPS с внешним адресом или домашний сервер с пробросом порта (порт можно выбрать нестандартный).
Доменное имя с возможностью редактировать DNS‑записи.
Управление DNS через Cloudflare (для автоматической выдачи сертификатов методом DNS‑проверки).
Установленные Docker и Docker Compose.
Базовые навыки работы в терминале и внимательность к деталям.

Готовим окружение: файлы проекта

.env: переменные окружения

Создайте файл переменных окружения и подставьте свои значения. Не храните реальные пароли в VCS, используйте менеджеры секретов или как минимум права доступа на файл.

# Домен (или поддомен), по которому будет доступен сервис
SERVER_HOST=my.host.name.com
# Внешний порт, на котором будет слушать Caddy
SERVER_PORT=5984
# Админ-пользователь CouchDB
COUCHDB_USER=obsidian_couchdb_user
# Пароль админа CouchDB
COUCHDB_PASSWORD=<your-password-here>
# Токен API для Cloudflare (с правами управлять DNS конкретного домена)
CLOUDFLARE_API_TOKEN=<cloudflare-api-token>

Совет по безопасности: выдавайте токену Cloudflare минимально необходимые права и ограничьте его конкретной зоной. Храните .env с правами на чтение только для владельца.

docker-compose.yml: два сервиса и одна сеть

version: '3.9'
services:
  couchdb:
    image: couchdb:latest
    container_name: couchdb
    volumes:
      - /home/$USER/obsidian/couchdb/data:/opt/couchdb/data
    environment:
      - COUCHDB_USER=${COUCHDB_USER}
      - COUCHDB_PASSWORD=${COUCHDB_PASSWORD}
    restart: unless-stopped
    networks:
      - couchdb_network

  caddy:
    build:
      context: .
      dockerfile: Dockerfile.caddy
    container_name: caddy
    ports:
      - "${SERVER_PORT}:${SERVER_PORT}"
    volumes:
      - /home/$USER/obsidian/caddy/data:/data
      - /home/$USER/obsidian/caddy/config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile
    environment:
      - CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
    restart: unless-stopped
    networks:
      - couchdb_network

networks:
  couchdb_network:
    driver: bridge

Пара моментов:

Порт CouchDB наружу не открывается вообще. Снаружи доступен только Caddy на порту из переменной SERVER_PORT.
Вынесенные тома упростят бэкапы и миграции: данные CouchDB и состояние Caddy будут лежать в понятных путях.
Переменные окружения подставляются из .env, что делает конфиг переносимым и воспроизводимым.

Dockerfile.caddy: сборка Caddy с плагином Cloudflare

FROM caddy:builder AS builder
RUN xcaddy build 
    --with github.com/caddy-dns/cloudflare

FROM caddy:latest
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Мы используем двухэтапную сборку: на первом этапе сборщик соберет бинарник Caddy со встроенным плагином DNS‑провайдера, на втором — подменим бинарник в официальном образе. Такой подход прост, прозрачен и воспроизводим.

Caddyfile: обратный прокси, TLS и CORS

Укажите в конфиге домен и порт. Caddy завершит TLS с валидацией по DNS у Cloudflare и отдаст запросы во внутренний контейнер CouchDB. CORS настроим под Obsidian, а предзапросы OPTIONS отдадим мгновенно.

# Хостнейм и порт внешнего сервиса
my.host.name.com:5984 {
    reverse_proxy couchdb:5984
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }

    header {
        Access-Control-Allow-Origin "app://obsidian.md"
        Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
        Access-Control-Allow-Headers "Content-Type, Authorization"
        Access-Control-Allow-Credentials "true"
        Access-Control-Max-Age 86400
    }

    @cors_preflight {
        method OPTIONS
        header Origin app://obsidian.md
    }
    handle @cors_preflight {
        respond "OK" 204
    }
}

Обратите внимание: заголовок Access‑Control‑Allow‑Origin строго ограничен на происхождение приложения Obsidian. Это уменьшает поверхность атаки и исключает произвольные кросс‑доменные запросы.

Запуск и первичная проверка

Firewall и старт контейнеров

Откройте выбранный порт на сервере, затем поднимите стек:

# пример для ufw
sudo ufw allow 5984

# запуск в форграунде (для первичной диагностики)
docker compose up

Если все корректно, Caddy автоматически получит сертификат, и контейнер CouchDB будет доступен за прокси. В следующий раз можно стартовать в фоне через detach‑режим.

Проверяем ответ CouchDB

Убедитесь, что сервер отвечает. Важный момент: для корректной проверки CORS добавьте заголовок Origin. Пример запроса может выглядеть так:

curl -v -H "Origin: app://obsidian.md" my.host.name.com:5984

В ответ вы должны увидеть код 200 и JSON с приветствием CouchDB. Если видите ошибку, сверяйтесь с журналами контейнеров и секцией «Частые ошибки и решения» ниже.

Вход через браузер

Откройте в браузере ваш домен с портом и войдите под учетной записью администратора, которую задавали через переменные окружения. Это позволит убедиться, что авторизация работает и интерфейс администрирования доступен.

Настройка Obsidian и плагина Self‑hosted LiveSync

Установка плагина

Откройте Obsidian и включите работу с плагинами из сообщества.
Найдите Self‑hosted LiveSync и установите его.
Активируйте плагин и откройте его настройки.

Мастер настройки (минимальная рабочая конфигурация)

На экране мастера укажите домен и порт сервера, имя пользователя и пароль администратора CouchDB.
Как правило, отдельную базу создавать не требуется — плагин создаст ее при подключении. Если что-то пойдет не так, вы можете заранее создать БД вручную через интерфейс администрирования CouchDB.
Настоятельно рекомендуется включить сквозное шифрование. В этом режиме шифруются не только содержимое заметок, но и имена файлов и метаданные. Хранить ключ шифрования нужно отдельно и очень надежно: потеря ключа сделает данные нечитаемыми.
Выберите пресет LiveSync, чтобы изменения применялись автоматически при сохранении.
Сохраните настройки и дождитесь старта синхронизации.

После успешной первичной синхронизации плагин предложит скопировать специальную зашифрованную строку настройки. Эту строку удобно использовать при подключении новых устройств: вставляете ее в настройках плагина — и получаете ровно такую же конфигурацию, включая ключ шифрования. Не публикуйте эту строку и не храните ее в открытом виде.

Подключение второго и последующих устройств

На новом устройстве установите Obsidian и плагин.
Вставьте сохраненную строку настройки или повторите шаги мастера вручную.
Проверьте «тест соединения» в настройках плагина: он должен подтвердить доступ к базе.
Дождитесь первичной синхронизации: для крупных хранилищ с вложениями это может занять заметное время.

Какие файлы синхронизировать

Имеет смысл исключить временные и кэш‑каталоги, например, корзину, превью или специфичные для плагинов временные папки. Это ускорит работу и уменьшит нагрузку на БД.
Решите, хотите ли вы синхронизировать папку конфигурации самого Obsidian. Если да — на разных устройствах интерфейс и плагины будут одинаковыми. Если нет — интерфейс можно настраивать по‑разному, а синхронными останутся только заметки.
Если у вас много вложений (изображения, PDF, видео), продумайте стратегию: все ли нужно синхронизировать на мобильных устройствах или стоит исключить тяжелые директории.

Тонкая настройка и эксплуатация

Производительность и масштабирование

Чистота набора: чем меньше «мусорных» файлов в хранилище, тем быстрее синхронизация.
Пакеты и задержки: при первой большой синхронизации не дергайте приложение, дайте ему закончить «первую волну» репликации. На некоторых устройствах мобильные ОС агрессивно «приспят» процесс — отключите экономию батареи для Obsidian.
Компакция: периодическая компакция баз CouchDB уменьшает размер на диске и повышает эффективность. Ее можно выполнять из админ‑интерфейса или по расписанию средствами CouchDB.
Ресурсы контейнеров: в Docker Compose можно ограничить/увеличить ресурсы по мере роста базы. Для медленных VPS следите за I/O и оперативной памятью.
Стратегия вложений: большие бинарные файлы увеличивают объем БД и время репликации. Возможно, часть «медиаархива» лучше хранить рядом, но вне основной синхронизации заметок.

Безопасность: что важно сделать сразу

Никакого «админ‑пати»: администратор задается через переменные окружения, вход в CouchDB только по логину и паролю.
Не публикуйте CouchDB напрямую: наружу — только Caddy. Это избавляет от лишних сканирований и уменьшает вектор атак.
TLS обязателен: сертификат выдается автоматически, но следите за корректностью времени на сервере — без точного времени обновление сертификата может сбоить.
CORS максимально узкий: разрешен только Obsidian. При необходимости можно дополнительно ограничить методы и заголовки.
Firewall: откройте только нужный порт. Если у вас есть белые IP, можно сузить доступ на уровне брандмауэра.
Cloudflare выступает только DNS‑провайдером: нестандартные порты не проксируются на «облачную» сеть, и это нормально — нам нужна лишь автоматизация DNS‑проверки для сертификатов.
Ключ E2EE храните отдельно и безопасно. Потеря ключа = потеря возможности расшифровать данные.

Резервное копирование и восстановление

У вас минимум три пласта защиты:

Снимки тома данных CouchDB: файловый бэкап каталога с данными контейнера. Это быстрый способ «заморозить» состояние.
Логическая выгрузка/загрузка базы специализированными инструментами: подойдет для переносов и миграций между версиями.
Репликация на «теплую» резервную CouchDB: опционально можно настроить вторую БД и периодически реплицировать в нее данные — это страховка на случай сбоя диска.

Всегда тестируйте восстановление на отдельном стенде. На реальной практике способность быстро поднять копию важнее, чем просто наличие архива.

Обновления и обслуживание

Перед обновлением — бэкап. Особенно это касается больших баз и переходов на новые версии CouchDB.
Обновляйте контейнеры постепенно: сначала стенд, потом прод. Автообновление полезно, но под контролем.
Следите за логами Caddy и CouchDB: неожиданные ошибки лучше ловить сразу, чем после «падения» синхронизации на всех устройствах.

Мониторинг и журналирование

docker logs для быстрых проверок.
Системные метрики сервера: CPU, память, диск, сеть. При резком росте нагрузки проверьте, не пошла ли массивная первичная репликация или компакция.
Статистика CouchDB: следите за размерами баз, числом документов, конфликтами.

Расширенные сценарии

Домашний сервер за NAT и альтернатива с туннелями

Если у вас домашний сервер без белого IP, можно использовать туннель до провайдера DNS. В этой схеме сертификат все равно можно получать через DNS‑проверку, а соединение между мирами обеспечит защищенный туннель. Следите за тем, чтобы порт и хост совпадали с конфигурацией Caddy.

Совместная работа (семья, небольшая команда)

Один общий «вальт» на нескольких пользователей возможен, но тщательно продумайте разграничение доступа. CouchDB управляет доступом на уровне базы, поэтому разные группы логично разнести по отдельным базам.
Если используется E2EE, общий ключ должен быть у всех участников. Храните его безопасно и раздавайте через надежные каналы.
Минимизируйте конфликты: договоритесь о структуре папок и избегайте одновременного редактирования одного и того же файла.

Переезд с других способов синхронизации

Выберите «главное» устройство с наиболее полной и актуальной версией заметок.
Поднимите CouchDB и настройте плагин на этом устройстве, дождитесь первичной выгрузки.
На втором устройстве подключайте плагин и дождитесь «затягивания» данных. Не запускайте параллельно старую синхронизацию, чтобы не плодить конфликты.
Сравните счетчики файлов и убедитесь, что критические директории и вложения на месте.

Мобильные устройства: нюансы

Режим энергосбережения может «убивать» фоновые процессы. Разрешите приложению работу в фоне и доступ к сети без ограничений.
Если хранилище большое, первый прогон может занять часы. Планируйте первую синхронизацию при подключении к зарядке и стабильному Wi‑Fi.
Осознанно подходите к вложениям на телефоне: возможно, имеет смысл исключить тяжелые каталоги.

Частые ошибки и решения

Имя не резолвится

Ошибка вида «не удалось разрешить имя хоста». Проверьте, что DNS‑запись создана, TTL отжился, а на клиенте нет кэшированного старого состояния. На сервере проверьте, что Caddy слушает нужный порт, и что домен совпадает с конфигом.

401 Unauthorized

Неверные имя или пароль администратора. Проверьте переменные окружения и заново создайте контейнер CouchDB с корректными значениями. Убедитесь, что в плагине указаны те же учетные данные.

403 или проблемы CORS

Если браузер/приложение жалуется на CORS, удостоверьтесь, что в Caddyfile правильно указан заголовок Access‑Control‑Allow‑Origin и предобработка OPTIONS. Происхождение должно соответствовать Obsidian.

Ошибки TLS/сертификата

Дата и время на сервере должны быть точными.
DNS‑проверка требует корректных прав у токена Cloudflare. Проверьте, что токен привязан к нужной зоне и может менять записи.
Если сертификат не обновляется, посмотрите лог Caddy: там будет причина отказа (лимиты выдачи, невозможность изменить запись и т. п.).

409 Conflict и дубликаты

При массовом переносе или при одновременных правках на нескольких устройствах возможны конфликты. Дождитесь завершения первичной репликации на одном устройстве, затем подключайте остальные. Плагин в большинстве случаев сам разрулит простые конфликты, но «сложные» лучше исправлять вручную.

База не создана автоматически

Иногда автоматическое создание БД не срабатывает. Зайдите в админ‑интерфейс, создайте базу вручную и снова нажмите «Тест соединения» в настройках плагина.

Проблемы с IPv6/IPv4

Если у вас есть AAAA‑запись, но сервер не слушает по IPv6, клиенты могут упираться в недоступный адрес. Либо удалите лишнюю AAAA‑запись, либо настройте полноценный IPv6 на сервере.

Порт закрыт

Проверьте брандмауэр: порт должен быть открыт снаружи. На сервере порт должен «слушать» Caddy, а не CouchDB; убедитесь, что docker‑компоновка пробросила верный порт.

Практические советы и «фишки»

Делайте снапшоты перед «большими» изменениями: обновления, массовые рефакторинги заметок, перенос вложений — все это проще откатить, когда есть точка возврата.
Отдельный «песочница‑вальт» для экспериментов: удобно для тестов плагинов и проверок производительности, чтобы не рисковать основной базой знаний.
Командный режим: по возможности разносите разные группы в разные базы, чтобы сократить вероятность конфликтов и случайных пересечений прав.
Старайтесь использовать стабильные наименования папок и плоскую структуру на верхнем уровне — это упрощает переносы и логику исключений.
Если вы активно добавляете медиа, рассмотрите хранение «тяжелых» материалов отдельно, а в заметках — ссылаться на них или встраивать по необходимости.

Сравнение с альтернативами: когда и что выбирать

Официальная синхронизация: минимум телодвижений, но меньше контроля и зависимости от внешнего сервиса.
Папки облачных провайдеров: только для простых сценариев и небольших вальтов. Конфликты и повреждения метаданных — частая история.
Git: прекрасно для версионирования, но дневная рутина превращается в фиксацию конфликтов. Хорошо как дополнительный бэкап, но не как основная синхронизация.
Self‑hosted LiveSync + CouchDB: чуть сложнее на старте, зато ваша инфраструктура, ваш контроль, ваше шифрование и гибкость.

Чек‑лист запуска

Получите домен и подключите зону к Cloudflare.
Установите Docker и Docker Compose на сервере.
Создайте .env с доменом, портом, админом CouchDB и токеном Cloudflare.
Положите рядом docker-compose.yml, Dockerfile.caddy и Caddyfile.
Откройте нужный порт в брандмауэре.
Соберите и запустите стек через docker compose.
Проверьте ответ CouchDB через прокси (с Origin заголовком).
Настройте плагин Self‑hosted LiveSync в Obsidian, включите E2EE, выберите пресет LiveSync.
Сделайте первую синхронизацию, проверьте, что все документы на месте.
Сохраните строку настройки в менеджере паролей и настройте второе устройство.
Настройте регулярные бэкапы и компакцию базы.

Итоги

Self‑hosted LiveSync с CouchDB — это «официальная синхронизация», только под вашим контролем: вы выбираете железо и хранилище, определяете правила безопасности и шифрования, сами решаете, как и когда делать резервные копии и обновления. Взамен вы получаете надежность репликации документ‑ориентированной БД, гибкость Docker и удобство Caddy с автоматическими сертификатами. Кейс показал, что для реальной работы с несколькими устройствами, большими вальтами и вложениями это решение стабильно и предсказуемо. Да, старт чуть сложнее, но уже к концу первого вечера вы забудете, что у вас «самодельное облако»: Obsidian просто синхронизируется и позволяет сосредоточиться на контенте.

Приложение: полные конфигурации

.env

SERVER_HOST=my.host.name.com
SERVER_PORT=5984
COUCHDB_USER=obsidian_couchdb_user
COUCHDB_PASSWORD=<your-password-here>
CLOUDFLARE_API_TOKEN=<cloudflare-api-token>

docker-compose.yml

version: '3.9'
services:
  couchdb:
    image: couchdb:latest
    container_name: couchdb
    volumes:
      - /home/$USER/obsidian/couchdb/data:/opt/couchdb/data
    environment:
      - COUCHDB_USER=${COUCHDB_USER}
      - COUCHDB_PASSWORD=${COUCHDB_PASSWORD}
    restart: unless-stopped
    networks:
      - couchdb_network

  caddy:
    build:
      context: .
      dockerfile: Dockerfile.caddy
    container_name: caddy
    ports:
      - "${SERVER_PORT}:${SERVER_PORT}"
    volumes:
      - /home/$USER/obsidian/caddy/data:/data
      - /home/$USER/obsidian/caddy/config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile
    environment:
      - CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
    restart: unless-stopped
    networks:
      - couchdb_network

networks:
  couchdb_network:
    driver: bridge

Dockerfile.caddy

FROM caddy:builder AS builder
RUN xcaddy build 
    --with github.com/caddy-dns/cloudflare

FROM caddy:latest
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

Caddyfile

my.host.name.com:5984 {
    reverse_proxy couchdb:5984
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }

    header {
        Access-Control-Allow-Origin "app://obsidian.md"
        Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
        Access-Control-Allow-Headers "Content-Type, Authorization"
        Access-Control-Allow-Credentials "true"
        Access-Control-Max-Age 86400
    }

    @cors_preflight {
        method OPTIONS
        header Origin app://obsidian.md
    }
    handle @cors_preflight {
        respond "OK" 204
    }
}