title: Services and integrations description: Distinguish AIRI’s hosted backend from its server channel and identify the prerequisites of external bot and desktop integrations.

Services and integrations

A browser application build does not start AIRI’s backend, game bots, messaging bots, or native desktop services. These systems have separate lifecycles and trust boundaries.

Read architecture for the application layers and operations for diagnostics.

The hosted backend

The server/ tree groups the resource API, standalone Auth service, and backend-private packages.

server/apps/api owns the resource API and shared database migrations.
server/apps/auth owns the standalone Better Auth and OIDC service.
server/packages/auth-shared owns Auth schema and principal contracts.
server/dev/caddy contains local routing for the shared API/Auth origin.

The source command pnpm dev:backend starts server/docker-compose.yaml. That example contains API, Auth, PostgreSQL, Redis, and Caddy services.

The Compose file publishes three loopback ports: PostgreSQL at 5435, Redis at 6379, and Caddy at 6112. The README’s narrower exposure description does not match that file.

The local Caddy route rejects /internal and /internal/*. It routes Auth paths to the Auth service and other requests to the API.

This is a development stack. Its example credentials and loopback routing are not a production deployment recipe.

The separate server channel

packages/server-runtime supplies an H3-based WebSocket server controller. The controller defaults to 127.0.0.1:6121 before caller overrides.

packages/server-sdk and packages/server-shared supply cross-runtime client and protocol packages. They remain outside server/ because applications and independent integrations consume them.

The root pnpm dev:server command selects this runtime. It does not select the hosted backend.

flowchart TD
    Stage[Stage application] -. account-backed services .-> API[Hosted resource API]
    API --> Auth[Standalone Auth]
    API --> Database[PostgreSQL and Redis]
    Stage -. connected integrations .-> Channel[Server channel]
    Channel --> Bot[Separate bot or plugin process]
    Bot --> External[External platform or game server]
    Direct[User-configured provider] --> Endpoint[Own inference endpoint]
    Stage --> Direct

The diagram separates optional paths. It does not make the hosted backend mandatory for every user-configured provider.

Integration examples and boundaries

Integration	Source guide	Prerequisites and limits
Discord bot	`integrations/discord-bot/README.md`	Discord application, bot credentials, gateway permissions, and inference or voice configuration
Telegram bot	`integrations/telegram-bot/README.md`	Bot token, database, generation endpoint, and embedding configuration
Minecraft bot	`integrations/minecraft/README.md`	Separate Mineflayer process and trusted Minecraft server
Computer-use MCP	`services/computer-use-mcp/README.md`	A separate execution service, executor mode, and platform permissions

These rows describe source guides, not integrations exercised by this showcase.

The Minecraft guide places the Mineflayer service on a deprecation path toward a Fabric-based runtime. It warns against untrusted public servers.

The computer-use guide describes a macOS-focused executor, a default dry-run mode, and an experimental Linux X11 backend. That description does not establish native control on this Linux host.

The repository contains other integration and plugin directories. Their presence does not prove that their external platforms, accounts, or devices are configured.

Before a real integration experiment

Read the selected integration’s source guide at the pinned revision.
Identify credentials, network destinations, device permissions, and external side effects.
Use a trusted test account or server.
Inspect a real connection and one intended operation.
Keep secrets and user content out of public evidence.

For a text-only experiment, start with workflows and avoid unnecessary external processes.

Source context

All references use the revision in provenance.

server/README.md, lines 7–14 and 61–78: service ownership and deployment-repository boundary.
server/docker-compose.yaml, lines 3–98: actual local services and ports.
server/dev/caddy/Caddyfile: local route boundaries.
packages/server-runtime/src/server/index.ts, lines 95–109: controller and default bind settings.
integrations/discord-bot/README.md, lines 5–49.
integrations/telegram-bot/README.md, lines 15–48.
integrations/minecraft/README.md, lines 1–17.
services/computer-use-mcp/README.md, lines 73–86.

Navigation: index · setup · capability-boundaries

Project AIRI

Explorer