{"slug": "show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games", "title": "Show HN: Vifu – An open-source game runtime for building AI-native games", "summary": "VifuDev released Vifu, an open-source game runtime for building AI-native games, under Apache-2.0. The runtime includes a Rust executable, Agent Gateway protocol, PostgreSQL database, and Next.js dashboard, supporting local and self-hosted deployments. Vifu provides stable project endpoints with profiles, bindings, API keys, and traces for connecting AI agents to games.", "body_md": "VifuDev is the open-source product for the Vifu endpoint runtime for local AI agents. It provides stable project endpoints with profiles, bindings, API keys, connection status, and traces, and connects agent providers through Vifu Agent Gateway.\n\nThe runtime command and protocol remain `vifu`\n\n.\n\nThe runtime, Agent Gateway protocol, PostgreSQL migrations, dashboard, and Docker deployment are all included in this repository under Apache-2.0.\n\nA complete Vifu installation has three layers:\n\n| Layer | Processes |\n|---|---|\n| Dashboard | The Next.js management console |\n| Runtime | One `vifu` binary configured as Server, Agent Gateway, or both |\n| Database | PostgreSQL |\n\nVifu ships one Rust executable: `vifu`\n\n. On first run it creates\n`~/.vifu/config.json`\n\nand `~/.vifu/providers.json`\n\n, then starts a loopback\nServer and Agent Gateway. The runtime configuration is only needed when a\ndeployment changes addresses or runs the two roles separately. A Gateway always\nconnects to its configured Server. Agent providers integrate through the Gateway\nrole.\n\n`local`\n\nand `self-hosted`\n\nare deployment modes. Native processes and Docker are\ntwo ways to run a self-hosted deployment; Docker is not a separate product mode.\n\nRun PostgreSQL, the configured Vifu runtime, and the Dashboard as separate native processes. PostgreSQL stays in Docker so local data survives restarts. Install Dashboard dependencies once:\n\n```\nbun install --frozen-lockfile\n```\n\nThen use separate terminals:\n\n```\n# Terminal 1: PostgreSQL\ndocker compose -f docker-compose.yml -f docker-compose.local.yml up -d postgres\n# Terminal 2: Vifu Server and Agent Gateway\ncd crates/vifu\ncargo run\n# Terminal 3: Dashboard\ncd npm-packages/dashboard\nbun dev\n```\n\nOpen `http://localhost:6791`\n\nto work through the local Dashboard. Stop the Rust\nruntime and Dashboard with `Ctrl-C`\n\n; PostgreSQL remains available for the next\nrun. Stop the local database with:\n\n```\ndocker compose -f docker-compose.yml -f docker-compose.local.yml down\n```\n\nDocker Compose starts the Dashboard, PostgreSQL, and two containers that reuse the same Vifu runtime image with separate role configurations:\n\n```\ncp .env.example .env\ndocker compose up -d\n```\n\nAfter that, restarting the stack from the repository root is just:\n\n```\ndocker compose up -d\n```\n\nOpen `http://localhost:6791`\n\nand create the first local administrator. Dashboard\nidentities and sessions stay in this deployment's PostgreSQL database. Signup\nstays open by default for additional local users. The first account receives the\ndeployment `admin`\n\nrole; later signups receive the deployment `operator`\n\nrole.\nSignup can be disabled with `AUTH_DISABLE_SIGNUP=true`\n\nor\n`VIFU_SIGNUP_ENABLED=false`\n\n.\n\nThe Compose stack includes Vifu Agent Gateway. Connect a supported provider\nunder `providers/`\n\nto discover agents, expose them through a project endpoint,\nand invoke them from your game. The Dashboard shows connected agents as the\nGateway discovers them.\n\nConfiguration, upgrades, persistence, and network exposure are documented in\n[Self-hosting Vifu](/vifudotdev/vifu/blob/main/docs/self-hosting.md).\n\nBuild the Vifu executable without Docker:\n\n```\ncargo build --release --locked -p vifu\n```\n\nRun `target/release/vifu`\n\ndirectly. It creates its loopback configuration on\nfirst use. To split the Server and Agent Gateway, or change their addresses,\nedit `~/.vifu/config.json`\n\nusing\n[config/runtime.example.json](/vifudotdev/vifu/blob/main/config/runtime.example.json) as a reference. A\ncomplete native installation also runs the Next.js Dashboard and PostgreSQL. See\n[BUILD.md](/vifudotdev/vifu/blob/main/BUILD.md) for verification.\n\nA self-hosted deployment keeps Dashboard identity and session state inside the deployment:\n\n``` php\napplication -> vifu (Server role) -> one multiplexed WebSocket -> vifu (Gateway role) -> provider\n                           |\n                           +-> PostgreSQL profiles, endpoints, keys, traces\n\nDashboard -> PostgreSQL users and web sessions\nDashboard -> Vifu Server through a server-side runtime credential\n```\n\nApplications call the OpenAI-compatible API. Existing AI SDKs only need a Vifu\nproject base URL, a project API key, and the target agent slug or ID as `model`\n\n:\n\n```\nPOST http://localhost:6790/my-project/v1/chat/completions\nAuthorization: Bearer vifu_pk_...\nContent-Type: application/json\n\n{\n  \"model\": \"town-guide\",\n  \"messages\": [{ \"role\": \"user\", \"content\": \"Open the north gate\" }],\n  \"stream\": false\n}\n```\n\nProject keys can follow every exposed agent in one project or an explicit set of agent bindings. The server stores only peppered key hashes and returns a raw key once when it is created. Removing an agent from the Gameplay canvas or turning off its exposure makes it unavailable through the project API.\n\nCanvas and Short Drama edit one revisioned gameplay graph. Publishing creates an immutable Game Release that a web game, native engine, or headless process can run through durable HTTP sessions and CloudEvents over SSE. Presentation bindings are versioned separately, so each host can map stable logical resource IDs to its own engine objects and assets.\n\nThe Dashboard's **Publish & API** page provides Game-only keys, cURL examples,\nrelease activation, immutable runtime-bundle export, and host-binding export.\nSee the [Game Runtime guide](/vifudotdev/vifu/blob/main/docs/game-runtime.md) for draft Preview, pinned\nAgent and Tool effects, sessions, reconnect, and host-action contracts.\n\nThe editor can export the current design, Agent Profile snapshots, structured\nresources, and managed media as one portable `.vf`\n\nproject file. Import creates\na new editable project and leaves deployment credentials and runtime history in\ntheir original environment. See [Vifu Project Files](/vifudotdev/vifu/blob/main/docs/project-files.md) for\nthe format and security boundary.\n\nThe Vifu Server role owns the core runtime contract:\n\n- routing Profile, Binding, and Endpoint CRUD;\n- Project CRUD and project-scoped HTTP invocation;\n- project API keys with all-agent or selected-agent access;\n- authenticated Agent Gateway sessions and heartbeat;\n- one WebSocket with multiple logical channels;\n- provider agent discovery and invocation through adapter contracts;\n- bounded queues, request timeout, cancellation, reconnect, and resume;\n- trace correlation and PostgreSQL persistence.\n\nThe Dashboard owns web authentication and keeps deployment authority on its server side. Local development uses no login and is restricted to loopback. Self-hosted deployments support local email/password in the same Dashboard, with optional self-host OIDC. Passwords use bcrypt, and opaque session hashes are stored in PostgreSQL. The Dashboard owns the auth implementation and initializes the auth tables it uses; append-only database history may still include older auth table migrations. The generated admin key is a server-side runtime credential for the Dashboard, recovery, and automation; it never enters HTML, browser logs, or the client bundle.\n\nProvider-specific setup lives under `providers/`\n\n. Register a supported provider\nto make its agents available to Vifu projects; each registration uses the same\nVifu Server, Dashboard, database, and Agent Gateway stack. Remote self-host\naccess must still use TLS even though the Dashboard has built-in login. See\n[SECURITY.md](/vifudotdev/vifu/blob/main/SECURITY.md) for the full boundary.\n\n```\ncrates/\n  vifu/             The single executable, configuration, and Agent Gateway\n  vifu-server/      Internal HTTP API, Agent Gateway relay, PostgreSQL runtime library\nnpm-packages/\n  dashboard/        One capability-driven Next.js Dashboard\nproviders/          Agent provider guides and examples\ndocker-compose.yml PostgreSQL, one Vifu runtime image, Dashboard, and Agent Gateway stack\nscripts/            E2E fixtures and public-repository checks\n```\n\nSee [BUILD.md](/vifudotdev/vifu/blob/main/BUILD.md) for source-development and verification commands.\nRead [CONTRIBUTING.md](/vifudotdev/vifu/blob/main/CONTRIBUTING.md) before opening a pull request, and use\nthe private process in [SECURITY.md](/vifudotdev/vifu/blob/main/SECURITY.md) for vulnerability reports.\n\nVifu is licensed under [Apache-2.0](/vifudotdev/vifu/blob/main/LICENSE). The license does not grant rights\nto the Vifu name or logos; see [TRADEMARKS.md](/vifudotdev/vifu/blob/main/TRADEMARKS.md).", "url": "https://wpnews.pro/news/show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games", "canonical_source": "https://github.com/vifudotdev/vifu", "published_at": "2026-07-22 16:41:26+00:00", "updated_at": "2026-07-22 16:52:35.705563+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools"], "entities": ["VifuDev", "Vifu", "Agent Gateway", "PostgreSQL", "Next.js", "Rust", "Docker"], "alternates": {"html": "https://wpnews.pro/news/show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games", "markdown": "https://wpnews.pro/news/show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games.md", "text": "https://wpnews.pro/news/show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games.txt", "jsonld": "https://wpnews.pro/news/show-hn-vifu-an-open-source-game-runtime-for-building-ai-native-games.jsonld"}}