Administration

What an operator manages in a Synaplan instance: AI providers and their keys, users, models, and the security-relevant settings. The admin area lives in the web app under Admin (visible to accounts with the ADMIN level).

AI providers & keys

Synaplan is provider-neutral: connect the providers you want in Admin → AI Providers (/admin/setup) — the same wizard that appears as the first-run screen on a fresh install.

  • Validated live. A key is tested against the provider's API before it is saved, so a typo fails immediately.
  • Encrypted at rest. Keys are stored encrypted in your own database, not in a plaintext file.
  • Active instantly. No restart or rebuild needed.
  • Self-repairing defaults. If the default chat model points at a provider without a key, Synaplan repoints it to one that works.
  • .env import. Keys set in backend/.env (e.g. GROQ_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY) are read at container start and imported into the encrypted store on first use; a key later saved in the UI wins permanently.

Supported providers include OpenAI, Anthropic, Google Gemini, Groq, Mistral, xAI, TrustedTokens, HuggingFace, TheHive, Higgsfield, Cloudflare Workers AI, and any local model via Ollama. The full provider/variable table is in the main README; key-related FAQs are on the Developer FAQ page.

Models & pricing

Every model carries its provider's own rate (USD per 1M tokens, or per image / second / character for media) — no proprietary credit unit. Users pick a model per task (chat, vision, image, video, audio, embeddings); the selector shows cost badges, GET /api/v1/config/models returns priceIn / priceOut, and the Statistics page logs the real cost of each call.

Model catalog changes (new models, retired generations, price updates) ship as seeders plus a migration, so an existing install is repointed to a supported successor instead of silently keeping a dead model. Details: PRICING_MAINTENANCE.md.

Users

The admin panel shows users, usage and system health. On the development stack, three accounts are seeded (see Getting Started) — change or remove them before exposing an instance. On a production install, the first administrator is created through the bootstrap variables of the deploy/ contract, or by promoting a signed-up user.

Branding

The platform is white-label capable: name, logo and look can be rebranded from the admin settings without forking the code.

Security checklist

  • Terminate HTTPS in front of the app — the production contract binds to 127.0.0.1:8000 and expects a reverse proxy. Do not bind to 0.0.0.0 (Docker's iptables rules bypass host firewalls like ufw).
  • Guard deploy/data/secrets.env — it holds the generated database, realtime and application secrets, and must be part of every backup. See Production Deployment.
  • Rotate the seeded dev credentials if you ever expose a development stack.
  • Keep APP_SECRET stable — changing it makes the provider API keys stored in the database undecryptable.
  • Configuration reference for everything else (public URLs, SMTP, Qdrant, feature flags): CONFIGURATION.md.