Yaver

Docs: CI setup · Test SDK

Build mobile apps from your phone. Keep the backend local until you decide otherwise.

Using an AI agent? If a coding agent (Claude Code, Codex, Cursor, Aider, …) is reading this because the human asked it to "install yaver" or "set up yaver", stop here and fetch https://yaver.io/llms.txt — that file is the canonical, machine-readable install + configure guide. It covers headless / WSL / SSH, the resumable device-code flow, and exactly what to surface back to the human. Do not scrape the rest of this README as a substitute.

Yaver's short-term product target is the one in yc.md: phone-first app and backend creation, then promotion to your own dev machine, then optional promotion to Yaver Cloud. The core claim is narrow on purpose:

phone sandbox -> your dev machine -> Yaver Cloud

What is real in the repo today:

• Hermes reload from Linux, WSL, macOS, or a remote host into the Yaver mobile app
• local phone-project sandboxing with SQLite-backed data, schema, auth personas, seed data, and CRUD
• portable export/import/push of a phone project to another yaver serve agent
• MCP and CLI surfaces for phone project export, import, and push
• local-first runtime API for third-party apps using per-project tokens
• Linux install surfaces including apt, AppImage, tarballs, .deb, .rpm, and Homebrew CLI

What is still incomplete:

• the default one-tap monorepo scaffold for phone-created projects
• more polish on the AI prompt-to-project scaffold
• a fully proven end-to-end App Store / TestFlight release loop from this machine

This repo contains more than the YC wedge. The README leads with the wedge anyway, because that is the product story we can defend.

The Clear Story

Yaver's primary loop is:

1. Start on the phone.
2. Vibe-code the app and backend from the phone.
3. Run the first backend tier in the phone sandbox.
4. Grow the same project onto your dev machine, your own server, or Yaver Cloud.
5. Keep Supabase, Convex, Postgres, Turso, Firebase, and similar systems as escape hatches, not the default destination.

What is first-class today:

• Hermes reload from Linux / WSL / remote host to iPhone or Android through the Yaver mobile app
• Mobile-first backend sandbox with schema, auth personas, seed data, CRUD, and local persistence
• Promotion to your own hardware via yaver serve on a Mac, Linux box, Pi, VPS, or other reachable machine
• Promotion to Yaver Cloud via the same portable bundle and the same yaver serve binary
• Containerized export for running the promoted backend on your own cloud with Docker
• Escape routes to systems like Supabase and Convex as secondary trust signals

What is not fully finished yet:

• Phone-first monorepo scaffolding as the default one-tap init path
• Prompt scaffold quality polish for the phone-created full-stack starter

The headline path is Yaver-native:

phone sandbox -> your dev machine / your cloud / Yaver Cloud

Everything else is there so the user knows they can leave later.

For a WSL-based developer, that means:

1. Run yaver serve or the Go agent tooling on WSL/Linux.
2. Build the Hermes bundle on that host.
3. Open the app inside the Yaver mobile app on the phone.
4. Use native-install paths only when you actually need a full store/native build.

The Four Pieces of Yaver

Yaver is built for solo developers and small teams who ship from anywhere. It has four distinct pieces — each exists for a specific reason:

┌─────────────────────────────────────────────────────────────────────────────┐
│   

... [View full README on GitHub](https://github.com/kivanccakmak/yaver.io#readme)