Деплой dApp: IPFS или Vercel

Фронт dApp — это статика. Его можно задеплоить даже без сервера: на IPFS или классически на Vercel.

Деплой dApp-фронта — публикация собранной статики. Поскольку бэкенда нет, варианты — обычный хостинг (Vercel) или децентрализованный (IPFS), что идеологически ближе к Web3.

Собранный React/Vue dApp — это набор статических файлов (HTML, JS, CSS). Ему не нужен сервер с логикой: всё взаимодействие идёт прямо из браузера в блокчейн. Поэтому деплой проще, чем у обычного приложения.

Вариант 1: Vercel/Netlify (привычно)

Самый простой путь — обычный фронтенд-хостинг. Подключаете репозиторий, на каждый push идёт сборка и публикация. Плюсы: быстро, CDN, домены, предпросмотры PR. Минус с точки зрения Web3: хостинг централизован — теоретически провайдер может отключить ваш сайт. Для большинства проектов это приемлемо.

Вариант 2: IPFS (децентрализованно)

Идеологически чистый путь: выложить статику в IPFS, чтобы фронт нельзя было «выключить». Сборку пиннят (через Pinata/Fleek/web3.storage), получают CID, и сайт доступен по ipfs://CID или через шлюз. Часто поверх вешают человекочитаемое имя через ENS (app.eth) или DNSLink. Так dApp становится по-настоящему устойчивым: даже если команда исчезнет, фронт продолжит работать, пока кто-то его пиннит.

build/  --(загрузка в IPFS)-->  CID  --(пиннинг)-->  всегда доступен
                                  |
                          ipfs://CID  или  app.eth (ENS)

Главная тонкость SPA на IPFS: роутинг

На IPFS нет сервера, который перепишет любые пути на index.html. Поэтому клиентский роутинг с «красивыми» путями (/profile) ломается при прямом заходе. Решения: использовать hash-роутинг (/#/profile) или относительные пути ассетов. Это типичная грабля деплоя SPA в IPFS.

Конфиг под среду

В сборку зашиваются адреса контрактов и RPC-ключи на нужную сеть. Держите их в переменных окружения по среде: одна сборка для тест-сети, другая для mainnet. Не коммитьте приватные ключи (их у фронта и не должно быть) и помните, что RPC-ключ в статике виден — ограничивайте его по домену.

Как работает под капотом

При деплое в IPFS вся папка сборки загружается как дерево файлов, и вы получаете CID корня. Любое изменение фронта меняет CID — значит, у каждой версии свой неизменяемый адрес. Чтобы пользователи всегда видели последнюю версию, поверх ставят изменяемый указатель: ENS-запись или DNSLink, которые обновляют на новый CID при релизе. Браузер (или расширение вроде IPFS Companion / шлюз) резолвит имя в текущий CID и отдаёт статику.

Частые ошибки

Абсолютные пути ассетов на IPFS. Сломаются под шлюзом с подпапкой; используйте относительные.
Хранить секреты в сборке. Всё в статике публично; приватных ключей быть не должно, RPC-ключ ограничивайте.
Забыть про роутинг SPA на IPFS. Прямые ссылки на маршруты не откроются без hash-роутинга.

Итоги

Фронт dApp — статика; деплой без бэкенда.
Vercel — просто и привычно; IPFS — децентрализованно и неотключаемо.
На IPFS следите за относительными путями и роутингом SPA, версии адресуются через CID + ENS/DNSLink.