oqto - setup configurator

Deployment

How oqto runs on your server. These choices affect isolation, security, and resource usage.

User Mode

Single User runs everything as your login user. Good for personal machines and development. All agents share your filesystem and permissions.
Multi User creates isolated Linux users (oqto_username-xxxx) for each platform user. Each gets their own home directory, systemd services, and file permissions. Required for shared servers and production.

Backend Mode

Local spawns agent processes directly on the host. Lower overhead, easier debugging, and full access to local tools (compilers, git, etc.).
Container mode (Docker/Podman isolation) is planned but not yet available.

Container Runtime

Auto-detect picks whichever is installed. Podman runs rootless by default which is better for security. Docker requires the Docker daemon.

Workspace Directory

Network

HTTPS, domain, and logging. If you are deploying to a server with a public domain, enable Caddy for automatic TLS.

Caddy Reverse Proxy Installs Caddy as a reverse proxy in front of oqto. Automatically obtains and renews Let's Encrypt TLS certificates for your domain. Handles HTTP-to-HTTPS redirect, WebSocket proxying, and static file serving. Skip this if you already have nginx/traefik or are running locally.

Domain

The public domain pointing to your server (A record). Caddy uses this to request a TLS certificate from Let's Encrypt. Port 80 and 443 must be reachable from the internet for the ACME challenge.

Log Level

Admin User

The first user account created during setup. This account has full admin privileges: managing users, viewing system status, and configuring providers. The password is never stored in this file, it will be prompted securely during installation.

Username

Email

Used for login and notifications. Can be changed later in the admin panel.

LLM Providers

Select which LLM providers to configure. oqto uses eavs as an LLM proxy that sits between agents and provider APIs. This gives you a single endpoint for all providers, per-user virtual API keys, usage tracking, and rate limit management.

API keys are not stored in this file. During setup, the installer will check your environment for existing keys (e.g. $OPENAI_API_KEY) and prompt for any missing ones. You can add or change providers later by editing the eavs config.

For azure ai foundry, pick the API type (openai chat, openai responses, or anthropic) and set the base url for your foundry resource (e.g. https://.services.ai.azure.com/openai/v1).

Anthropic Claude models (Sonnet, Opus, Haiku) ANTHROPIC_API_KEY

OpenAI GPT-4o, o1, o3, Codex OPENAI_API_KEY

Google Gemini 2.5 Pro, Flash GEMINI_API_KEY

OpenRouter Aggregator: access 200+ models via one key OPENROUTER_API_KEY

Groq Ultra-fast inference (Llama, Mixtral) GROQ_API_KEY

Mistral AI Mistral Large, Codestral MISTRAL_API_KEY

xAI Grok models XAI_API_KEY

Add custom / self-hosted providers Azure OpenAI, AWS Bedrock, Ollama, vLLM, LM Studio, SGLang, llama.cpp, or any OpenAI-compatible endpoint.

You need at least one provider for agents to work. Anthropic + OpenAI covers most use cases. Add more providers later: ~/.config/eavs/config.toml

Agent Tools

CLI tools available to AI agents in their workspace. These extend what agents can do beyond code editing, searching the web, managing memory, generating documents, etc. All tools are installed to /usr/local/bin and available to all users.

Install all tools (recommended) Installs the full toolkit. Required tools (mmry, hstry, trx) are always installed even if you opt out of optional tools. Total disk usage is ~200MB.

agntz Agent toolkit: wraps memory, issues, file reservations, and inter-agent messaging into a single CLI. Required for most agent workflows. mmry (required) Semantic memory storage and search. Agents use this to persist insights across sessions, architecture decisions, API patterns, debugging notes. Uses local embeddings (no external API calls for search). hstry (required) Chat history daemon (gRPC API, SQLite-backed). Stores all conversation messages in a structured, searchable format. Required for the chat UI. scrpr Web content extraction. Fetches and cleans web pages into markdown that agents can read. Handles JavaScript-rendered sites. sx Web search via a local SearXNG instance. Agents can search the internet without sending queries to external search APIs. Binds to localhost only. Enabling this also installs SearXNG and Valkey (for caching). tmpltr Document generation from Typst templates. Create PDFs, reports, and formatted documents programmatically. Also installs the Typst compiler. sldr Modular presentation builder powered by Slidev (sli.dev). Create, reuse, and brand slide decks from markdown. Also installs Slidev globally. ignr Gitignore file generation. Quickly create .gitignore files for any language or framework. trx (required) Issue and task tracking that lives inside the repo (.trx directory). Agents use this to plan work, track progress, and coordinate across sessions.

Server Hardening

Security measures for production servers exposed to the internet. These are standard Linux hardening practices and are strongly recommended for any public-facing deployment. Skip for local development.

Enable server hardening

SSH Port

Changing from the default 22 reduces automated brute-force attempts. Common alternatives: 2222, 2200, or any high port. Make sure your cloud provider's firewall allows the new port before changing.

Firewall (UFW) Configures UFW to allow only SSH, HTTP (80), and HTTPS (443). All other inbound ports are blocked. Outbound traffic is unrestricted. Fail2ban Monitors SSH logs and temporarily bans IPs after 3 failed login attempts. Effective against brute-force attacks. Bans last 10 minutes by default. SSH hardening Disables password authentication (key-only), disables root login, limits max auth tries, and enables strict mode. Make sure you have SSH key access configured before enabling. Automatic security updates Enables unattended-upgrades for security patches. Only security updates are applied automatically, no major version changes. Reduces the window of vulnerability for known CVEs. Kernel security parameters Applies sysctl settings: disable IP forwarding, enable SYN cookies, ignore ICMP redirects, enable reverse path filtering, and restrict kernel pointer exposure. Standard hardening for any Linux server.

Setup Configurator