Aller au contenu
SVEDA
FR
Menu

RUNTIME

Un runtime Rust autonome.

sveda-server écoute par défaut sur 0.0.0.0:8787. Il possède la boucle, le catalogue, les tools et MCP. Routes, auth et déploiement restent les vôtres.

Commencer Runtime docs

Un runtime Rust autonome.

sveda-server écoute par défaut sur 0.0.0.0:8787. Il possède la boucle, le catalogue, les tools et MCP. Routes, auth et déploiement restent les vôtres.

sveda-server est un runtime Axum autonome. Boucle agent, catalogue, tools et host MCP à côté de votre app sur 0.0.0.0:8787 — hors du cycle de requêtes.

sveda-server

binary

:8787

default bind

Axum

HTTP stack

The problem

Rolling an agent usually means a control plane in the same process as the product. Health becomes “the app is up.” Tools, models, and MCP share your request workers. A sidecar should be a binary you can bind, probe, and proxy.

Loop in the request cycle

Prompt routers inside Laravel, Rails, or Node HTTP handlers stall the page. sveda-server owns the agent loop on its own port.

Orchestration as a repo

Workers and catalogs sprawl before a first token. The open-source runtime is one binary, configured with sveda.yaml.

Opaque liveness

A 200 on your app index does not mean the agent can stream. GET /sveda/health answers { ok: true, runtime: "rust" }.

How Sveda does it

sveda-server is Axum. Default bind is 0.0.0.0:8787, override with SVEDA_BIND. Your host proxies or calls it. POST /sveda/stream is required for a turn. Token mint, health, config, message, histories, and document extract sit beside it.

Bind beside the host

The binary listens on its own address. You do not mount it as a Laravel package or a Vue plugin.

  • default 0.0.0.0:8787
  • SVEDA_BIND overrides the socket
  • proxy /sveda/* if you want one origin

Routes the client expects

The JS client only needs stream to send. The rest of the surface is optional until you wire it.

  • POST /sveda/stream
  • POST /sveda/embed/token
  • GET /sveda/health and GET /sveda/embed/config

Same process, more verbs

Non-stream turns, chat histories, and document extract share the runtime — not a second service.

  • POST /sveda/message
  • histories list and detail
  • POST documents/extract
SVEDA-SERVER 0.0.0.0:8787

GET /sveda/health

POST /sveda/embed/token

GET /sveda/embed/config

POST /sveda/stream

POST /sveda/message

histories

documents/extract

runtime: rust

Probe it like a sidecar.

Start the binary, then GET /sveda/health. The body is JSON: ok true, runtime rust. That is the contract that the process on :8787 is sveda-server, not a mock in your app.

Catalog, tools, and host MCP execute here. The JS client does not run the model loop. Embed config is HTTP on the same listener. Change the bind with SVEDA_BIND when 8787 is taken.

See the runtime docs for the route list. The product copilot solution keeps this process next to an existing app.

health.json GET 
$ curl -s http://127.0.0.1:8787/sveda/health

{
  "ok": true,
  "runtime": "rust"
}

Related

JS client

SvedaClient posts to this runtime. session.send is the turn.

Models

The catalog and failover list live on sveda-server, not in the UI.

MCP & tools

Builtin tools and host MCP execute inside the runtime.

Runtime docs

Bind address, Axum routes, health, and settings.

Get started

Run sveda-server, then attach @sveda-ai/core.

Product copilot

Sidecar next to the host. Routes and auth stay yours.

Bind :8787. Leave the app alone.

Run sveda-server. Probe GET /sveda/health. Proxy POST /sveda/stream when you want one origin.

Commencer