DocumentationDevelopment
Rust · 0.1.0
Development
Set up the Rust and React development loop, find the code for your change, run the relevant checks and build a real release artifact.
Prepare the required tools
You need an authorized checkout of the application repository. This landing website is a separate static project and cannot run the backend. The versions below come from this distribution's toolchain and package manifests; use the locked dependencies instead of replacing them with an upstream Memos toolchain.
| Tool | Requirement | Used for |
|---|---|---|
| Rust | 1.94.0; rustfmt and Clippy | Backend and Rust protocol bindings |
| Node.js | 24 or newer according to package.json | React/Vite frontend |
| pnpm | 11.0.1 | Frozen frontend dependency installation |
| C/C++ and CMake | Available in the build environment | Native dependencies, including SQLite and audio libraries |
| Buf | Needed when changing protocols | OpenAPI and TypeScript generation |
Start a two-terminal development loop
Use a dedicated development shell without production /etc/secrets mounts. Explicit SQLite and an empty DSN keep inherited database variables from selecting a real database; clearing socket/demo variables keeps this recipe on the stated listener. Run the backend from the repository root with its own data path. In a second terminal, install frontend dependencies and run Vite. Open the URL Vite prints rather than assuming a fixed frontend port. The development proxy targets the backend on port 8081. Use test accounts and synthetic notes.
# Terminal 1: application repository root
unset MEMOS_UNIX_SOCK MEMOS_DEMO
cargo run --locked --bin memos -- \
--addr 127.0.0.1 --port 8081 --driver sqlite --dsn '' --data ./dev-data
# Terminal 2: application repository root
cd web
pnpm install --frozen-lockfile
pnpm devLocate the responsibility you are changing
Read the relevant tests before modifying behavior. Keep business rules separate from HTTP transport handling, and regenerate protocol outputs from their canonical definitions.
| Area | Source location |
|---|---|
| CLI and process startup | crates/amemos/src/main.rs |
| HTTP/REST/Connect adapters | crates/amemos/src/server/ |
| API behavior | crates/amemos/src/api/ |
| Persistence and migrations | crates/amemos/src/store/ and store/migration/ |
| Protocol definitions | proto/api/v1/ and proto/store/ |
| React interface | web/src/ |
| Behavior and database tests | crates/amemos/tests/ |
Use the guide that matches the next outcome
For a new workstation, finish development setup. For an executable with the real web interface, follow building: a debug fallback page is not a release UI. For a code change, use testing to select frontend, backend, protocol and disposable-database checks. Before review, use the contribution checklist to state the change, its evidence and what remains untested.
Confirm that the loop works
Read /healthz on the local backend, open the Vite interface, create one test memo, refresh and edit it. Then run a focused test for the area you changed. If the backend starts but shows a development placeholder, use the Vite URL or generate release assets; if Vite cannot reach the API, check the backend port and its startup logs first.
curl --fail http://127.0.0.1:8081/healthz
cargo fmt --all -- --check
# For a full embedded frontend + release binary:
sh scripts/build.sh
./build/memos --version