Архитектура

Lizard организует всё, что вы деплоите, в иерархию из трёх уровней, плюс управляемые аддоны, прикреплённые к проекту.

workspace
└── project
    ├── service (app)          ← built from GitHub or an upload
    ├── service (worker)       ← background job, no HTTP port
    └── addons
        ├── postgres
        ├── redis
        └── s3

Рабочее пространство

Рабочее пространство объединяет ресурсы аккаунта или организации. Вы состоите хотя бы в одном, а биллинг, участники и проекты находятся в нём. Посмотреть доступные:

lizard workspace list

Многие команды принимают -w, --workspace <ws>, чтобы уточнить цель, когда одноимённые проекты существуют в разных рабочих пространствах. Владелец может ограничить, сколько песочниц рабочее пространство запускает одновременно и сколько CPU, памяти и диска оно использует, командой lizard workspace limits (см. lizard workspace).

Проект

Проект объединяет связанные сервисы и аддоны внутри рабочего пространства. Ваша рабочая директория связывается с проектом, и эта связь (хранится в ~/.lizard/config.json) сообщает CLI, с чем вы работаете.

lizard init --name my-project   # create or select a project, link the cwd
lizard link --project my-project  # link to an existing project
lizard status                   # show the current directory's link
lizard unlink                   # remove the link
lizard project list             # all projects in the workspace

Папка без связки использует проект по умолчанию вашего аккаунта: самый старый проект в вашем личном рабочем пространстве, у нового аккаунта это <username>'s Project. lizard up, lizard add, lizard sandbox create и другие команды проекта работают с ним, пока вы не свяжете папку или не передадите --project.

Совет: Используйте имя репозитория или директории для проекта, а для сервисов — имена в стиле приложений (api, worker, web).

Сервис

Сервис служит единицей деплоя. Его источник может быть одним из:

• github — подключённый репозиторий GitHub. Пуш в отслеживаемую ветку вызывает повторный деплой.
• upload — тарболл, загруженный через lizard up.

Каждый запущенный сервис работает как отдельный изолированный под с политикой сети default-deny, сгенерированным доменом <name>-<suffix>.onlizard.com (у более старых сервисов остаётся <words>.<region>.onlizard.com) и автоматическим TLS. Это разделение — вы предоставляете контейнер, платформа его запускает — называется container as a service, а в блоге описано, что ещё остаётся на вашей стороне. Инспектировать и управлять сервисами можно с помощью:

lizard ps                       # list services with status + URL
lizard service show             # full config as JSON
lizard service set <svc> --set <field>=<value>
lizard service rename <new-name> --service <svc>
lizard service delete --service <svc>

Чтобы остановить сервис, не удаляя его, используйте lizard pause; чтобы он засыпал без трафика, — lizard sleep.

Поля конфигурации сервиса плоские и отображаются 1:1 в схему на проводе (например, repoUrl, branch, buildCommand, startCommand, containerPort, rootDirectory). Вложенности build.* / deploy.* нет. Полный список см. в lizard service.

App-сервисы и воркеры

По умолчанию сервис — HTTP-приложение, слушающее порт (по умолчанию 3000) и доступное на своём домене. Сервису, который не слушает порт — потребителю очереди, реконсилеру или поллинговому циклу — следует запускаться в режиме воркера, установив containerPort=0. Воркеры пропускают инъекцию порта, проверку достижимости и регистрацию в балансировщике.

Управляемые аддоны

На уровне проекта вы создаёте аддоны: Managed Postgres, Managed Redis и S3-совместимое Managed Object Storage:

lizard add postgres redis s3

Каждый аддон предоставляет фиксированный набор переменных окружения, которые сервисы используют по ссылке (${{<addon-name>.KEY}}). Подробнее в разделе Управляемые аддоны.

Межресурсные ссылки

Любое значение сервиса или аддона можно сослаться из окружения другого ресурса с помощью:

${{<name>.<KEY>}}

Ссылки разрешаются во время деплоя против объединённого окружения цели. Они сопоставляются с текущим именем цели: если вы переименуете сервис или аддон, обновите все ссылки, использующие старое имя. Ссылка на несуществующую цель или ключ разрешается в пустую строку (деплой не падает); выбрасывают ошибку только циклические ссылки.

# Wire a service to the project's Postgres
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api

Проверьте, что ссылка разрешилась. Лог сборки выводит предупреждение для каждой ссылки, разрешившейся в пустое значение, а secrets list показывает, что сохранено:

lizard logs --build --service api
lizard secrets list --service api --show

Переменные, внедряемые платформой

Каждый сервис автоматически получает эти переменные (их нельзя переопределить):

Как они взаимодействуют с вашими переменными и полный порядок приоритетов см. в разделе Переменные и секреты.

Обновлено 21 октября 2026 г.