Self-hosted environment orchestration

Ship branches,not collisions.

qahost builds an isolated environment for a target service and its complete dependency graph—without touching the shared develop stand.

qahost / plan
$ qahost plan app task=APP-123

resolving graph...
✓ app                 target
✓ identity            dependency
✓ notifications       dependency
✓ billing             dependency
✓ PostgreSQL / Redis / RabbitMQ / MSSQL

$ qahost stand up app-123
ready  app.app-123.environments.example.com

One task. One environment.

The whole backend, resolved from configuration.

Catalog references describe application dependencies and infrastructure allocations. qahost turns that graph into a disposable, observable environment.

01 / GRAPH

Transitive dependencies

A service URL or database reference adds the required service, owner, migration, and resource.

02 / BRANCHES

Task-aware revisions

Matching task branches are selected across repositories with deterministic fallbacks.

03 / DATA

Isolated allocations

Dedicated databases, roles, vhosts, Redis DBs, and buckets share a resource-efficient pool.

04 / CONTROL

Telegram, API, GitLab

Engineers and automation share ownership rules, quotas, lifecycle, logs, and credentials.

05 / LIFECYCLE

TTL and garbage collection

Warnings, extensions, teardown, reconciliation, and GC keep the host clean.

06 / LIMITS

Bounded by design

systemd, user quotas, and container limits protect host capacity.

From commit to stand

A predictable deployment path.

01
Resolve
Read the catalog, follow references, select branches, and calculate the complete plan.
02
Allocate
Reserve databases, users, queues, cache indexes, buckets, network, and capacity.
03
Build and prepare
Reuse CI images or build locally, run migrations, seed data, and copy golden templates.
04
Publish and observe
Start Compose, route component hosts, and expose logs and credentials to the owner.

Architecture

Small control plane. Standard runtime.

Docker Compose, SQLite, and explicit YAML. No Kubernetes cluster required.

InputsTelegram
GitLab webhooks
HTTP API
→
qahostplan · build · allocate
deploy · TTL · GC
→
RuntimeDocker Compose
Traefik
shared data pool

Human-readable hosts

Every task becomes its own namespace.

Short component aliases stay clear in reviews, tickets, and reports.

app.app-123.environments.example.com
admin.app-123.environments.example.com
search.app-123.environments.example.com
callbacks.app-123.environments.example.com

Own the environment

Give every branch a safe place to run.

Start with the example catalog, connect GitLab, and create complete environments without coordinating changes to develop.

Self-hosted управление стендами

Ветки отдельно.Develop цел.

qahost разворачивает изолированное окружение для целевого сервиса и полного графа его зависимостей, не затрагивая общий стенд develop.

qahost / plan
$ qahost plan app task=APP-123

разрешение графа...
✓ app                 цель
✓ identity            зависимость
✓ notifications       зависимость
✓ billing             зависимость
✓ PostgreSQL / Redis / RabbitMQ / MSSQL

$ qahost stand up app-123
готов  app.app-123.environments.example.com

Одна задача. Один стенд.

Весь backend из декларативного каталога.

Ссылки описывают сервисные зависимости и инфраструктурные ресурсы. qahost превращает граф в одноразовое наблюдаемое окружение.

01 / ГРАФ

Транзитивные зависимости

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

02 / ВЕТКИ

Ревизии одной задачи

qahost ищет ветки с тем же ключом задачи и применяет предсказуемые fallback-правила.

03 / ДАННЫЕ

Изолированные ресурсы

Отдельные базы, роли, vhost, Redis DB и bucket работают поверх общего пула.

04 / УПРАВЛЕНИЕ

Telegram, API, GitLab

Разработчики и автоматизация используют общие правила, квоты, логи и доступы.

05 / TTL

Удаление и GC

Предупреждения, продление, teardown, reconcile и GC поддерживают порядок.

06 / ЛИМИТЫ

Защита хоста

systemd, пользовательские квоты и лимиты контейнеров защищают сервер.

От коммита до стенда

Предсказуемый путь развёртывания.

01
Разрешить граф
Прочитать каталог, выбрать ветки и построить полный план.
02
Выделить ресурсы
Зарезервировать базы, роли, очереди, Redis DB, bucket, сеть и квоту.
03
Подготовить
Использовать CI-образы или собрать локально, выполнить миграции и сиды.
04
Опубликовать
Запустить Compose, настроить Traefik и выдать владельцу ссылки, логи и доступы.

Архитектура

Маленький control plane. Стандартный runtime.

Docker Compose, SQLite и явный YAML. Кластер Kubernetes не требуется.

ВходыTelegram
GitLab webhooks
HTTP API
→
qahostplan · build · allocate
deploy · TTL · GC
→
RuntimeDocker Compose
Traefik
общий пул данных

Понятные адреса

Каждая задача получает своё пространство имён.

Короткие имена удобно отправлять в review, задачи и отчёты.

app.app-123.environments.example.com
admin.app-123.environments.example.com
search.app-123.environments.example.com
callbacks.app-123.environments.example.com

Своя инфраструктура

Дайте каждой ветке безопасное место для запуска.

Начните с примера каталога, подключите GitLab и создавайте полные окружения без координации изменений на develop.