# Get started

> Install the Sollar CLI, scaffold a mini app, and run it against a test organisation — no approval, no admin, no production data.

Source: https://miniapp.sollar.com/start/

---

You need Node.js 20 or newer and a Sollar account. You do **not** need an approved developer entity,
an administrator, or permission from anyone. That comes later, and only if you publish publicly.

## 1. Install

```sh
npm install -g @sollar/cli
sollar login
```

`sollar login` opens your system browser for OIDC sign-in. The token lives in your OS keychain.
Nothing is written to a config file — no key, no token, no secret, ever.

## 2. Create a test organisation

```sh
sollar org create --name "My sandbox"
```

A **test organisation** is a throwaway tenant with synthetic users, synthetic conversations and
synthetic files. Inside it:

- permission and configuration changes take effect **immediately**, with no administrator review;
- there is no path to production data, by credential or by network;
- development-signed packages are accepted.

You may hold **three** at a time. They are real infrastructure, so they are not free.

## 3. Scaffold

```sh
sollar init my-mini-app          # or: --template react | vue
cd my-mini-app
```

You get:

```
my-mini-app/
├── manifest.json          the contract: identity, permissions, network, actions
├── sollar.config.json     build config — commit this
├── .sollar/local.json     your machine's preferences — gitignored
├── AGENTS.md              instructions for coding agents
├── CLAUDE.md              one line: @AGENTS.md
└── src/
    ├── main.ts
    ├── actions.ts         your sollar.actions.handle() registrations
    └── pages/
```

> **NOTE**
`AGENTS.md` is the name Codex, Cursor, Jules, Factory and Aider look for. Claude Code reads
`CLAUDE.md` and does **not** read `AGENTS.md`, so `CLAUDE.md` simply imports it with `@AGENTS.md`.
One file is the source; the other is a pointer. Never duplicate the instructions by hand — hand-kept
duplicates drift, and they drift silently.

## 4. Run

```sh
sollar dev
```

This starts a local server and opens your mini app in a Sollar client in developer mode. You get
hot reload, and you get the standard web toolchain: Chrome DevTools on Android, Safari Web Inspector
on iOS. Sollar does not ship its own debugger, because it does not need to — the runtime *is* the
web platform.

Change a CSS file and it applies without reloading. Change `manifest.json` and the app reloads
completely: permissions, routes and the network allowlist are re-validated by native code, and
applying that hot would let the runtime and your source disagree about what is authorised.

## 5. Seed some data

```sh
sollar seed --profile erp
```

Populates the test organisation with people, an org chart, conversations and files. Use it. The
alternative — pointing at a real staging system "just to see it work" — is how test credentials end
up in production code.

## 6. Check it before you ship

```sh
sollar validate       # manifest, CSP, network allowlist, SBOM
sollar conformance    # runs against both engines
```

`sollar conformance` matters more than it looks. iOS runs JavaScriptCore and Android runs V8 — the
engines differ, permanently, because [Apple Guideline 2.5.6](/compliance/apple/) mandates WebKit.
The conformance suite is how you find out before your users do.

## Next

- [Your first mini app](/start/first-mini-app/) — a working approvals app, end to end
- [Connect a backend](/start/connect-a-backend/) — authenticating against your own ERP
- [Publish](/start/publish/) — tenant-private or public store