Self-hosting Vifu
The standard service deployment runs the Console, Vifu Server, Vifu Agent Gateway, and PostgreSQL. Server and Gateway can run in the same process or as separate roles. Choose one starting path:
| Goal | Guide |
|---|---|
| Try Vifu on one computer | Run Vifu locally |
| Run one persistent multi-service deployment | Run with Docker |
| Develop the Console or Rust runtime | Run Vifu locally |
Both paths run the same Runtime and use the same project model. The release binary is the shortest first run. Docker supplies PostgreSQL and separately managed Server, Gateway, and Dashboard services.
Services
| Service | Purpose | Default address |
|---|---|---|
| PostgreSQL | Projects, releases, sessions, credentials, and logs | 127.0.0.1:5432 |
| Vifu Server | Project HTTP, realtime, Gateway APIs, and public Dashboard origin | 127.0.0.1:6790 |
| Dashboard service | Server-side authority used behind the Server origin in Docker | internal dashboard:6791 |
| Agent Gateway | Provider discovery and invocation | Connects internally to Vifu Server |
Agent Gateway is an optional remote provider transport and connects to Vifu
Server. An embedded application uses VifuRuntime directly and registers its
providers in process; see
Embed the runtime.
After the stack is healthy, create a project and continue with Agent Providers.
Remote Gateway enrollment
The managed Docker and combined local shapes use deployment bootstrap registration. A Gateway on another machine uses a project owner's one-time enrollment token:
- exchange the owner's access token through
POST /v1/auth/exchange; - create a token through
POST /v1/project/{slug}/agent-gateway-enrollments; and - provide it to Gateway once through
VIFU_AGENT_GATEWAY_ENROLLMENT_TOKENorVIFU_AGENT_GATEWAY_ENROLLMENT_TOKEN_FILE.
Gateway consumes the token, registers its own long-lived credential, and stores that credential in a session file scoped to the Server URL. Enrollment tokens expire after five minutes, are single-use, and are rejected in persistent runtime configuration.
Before remote access
The included ports bind to loopback by default. For remote access, keep PostgreSQL private and place the Console and runtime behind HTTPS and your chosen network access controls. Never expose provider credentials, bootstrap values, or the Console's server credential to browser code or application clients.