Start with a small project.

1. Prepare your trial

• Choose your computer in the portal: Windows x64 or Apple Silicon Mac. A target marked Not published yet has no public installer. Intel Mac support is not available.
• Choose a small project you can afford to restore. Keep a separate backup; exclude production data, secrets and other people's private information.
• Use an account and endpoint you are authorized to use. Check its model access, billing and spending controls before any provider request.
• Keep the first session local and review requested actions. Leave optional integrations, remote execution and media imports for separately agreed trials.

Local chat commands use the Sandbox. The Sandbox isolates those commands and discards their output files; persistent project edits use the reviewed edit tools. Manual Terminal, goals and task workspaces are separate. Review your exact release notes and run only commands you understand.

Mac distribution is still in preparation. Public Mac downloads require completed signing, notarization and installation checks. The minimum supported macOS version is still pending. An internal preview is not a public release. Keep macOS security protections enabled and wait for release instructions.

Before upgrading, stop work and close Solara. Keep separate backups of your project and app profile. An older installer may not open an updated profile; downgrading is not a recovery plan.

2. Account and release access

Signup is open through the Solara account portal. Enter an email you control and open the fresh sign-in link sent to that inbox. Email verification activates a new account automatically; no manual approval is required. An administrator can revoke or restore access from the admin panel. Account activation does not mean a build is available.

In the portal, Overview shows any release available to your account, its notes and SHA-256 checksum. If it says Not published yet or Download unavailable, wait for release instructions. Do not use an unofficial mirror or a forwarded download ticket.

Use only the build specified in the release instructions. Compare its full published SHA-256 with the downloaded file before opening it. An unsigned alpha has no verified code-signing publisher; a checksum only compares the file with the published record.

If the build is signed, its signature must be valid and its publisher must match the release instructions. Stop if the checksum differs, a build described as signed has no signature, or a supplied signature is invalid or identifies a different publisher.

Windows may show an unknown-publisher or reputation warning, and device policy may block installation. Keep protections enabled. If installation is blocked or you are unsure about the source, stop and use the support route. This alpha policy does not authorize bypassing device restrictions.

Desktop sign-in begins with Continue in browser. Review the account on the desktop authorization screen, continue, then choose Open Solara on the return page. If you are not signed in, first verify your email using the fresh link sent to your inbox. Revoked access needs administrator restoration. If the flow sends a link for a particular desktop request, use that exact link. Wait at least 60 seconds before requesting another.

3. Choose your provider and model

1. Open Settings → Connections, Git & environments → Manage models.
2. In Models & providers, choose the provider you intend to use. Enter its connection details only in the appropriate fields. If you use an editable base URL, verify that it is the endpoint you trust.
3. Select Save connection. This saves the configuration and requests the provider's model list; it is a network action. Opening an already configured provider or selecting Refresh models can also contact that provider.
4. Choose an exact Model, or enter the exact Model ID when needed, then select Use model. Check the active provider and model before sending.

Saving or refreshing a connection does not itself select a different model. If a model or region is unavailable, keep the error and correct that connection deliberately. If you choose a provider's auto route, that route can choose the underlying model; use an exact ID when you need a repeatable trial.

Messages, supplied history, recalled memory, relevant project context and tool results may be sent to your configured provider. Plan requests also use the provider and can incur charges. Review the data-handling notice before adding attachments: audio/video preparation can request transcription before you send a chat message.

4. Inspect in Plan; review Build actions

Open your trial project and a conversation, select Plan, and wait for that mode to be confirmed. New conversations otherwise default to Build. For a small first request, ask:

Explain this project's structure and propose one small README clarification. Do not change files or run commands.

Plan permits file inspection, search, read-only Git information, attachments, diagnostics and questions. Its model tools cannot edit files, execute commands or start execution tasks. It does not make provider requests offline or free.

If you want the proposed change, explicitly select Build or Switch to Build. Your history and draft remain; switching does not send a message. Plan/Build is separate from provider/model and Solo/Team selection.

Send a small implementation request with Auto still off. Review the exact files, diff, command, working directory and execution target in each applicable approval. Reject anything outside your intended change. If a file changed after review, request a fresh proposal instead of trying to reuse stale approval.

If the mode is loading or an error asks you to Refresh mode, reconcile it before sending again. A disabled mode switch can mean work, queued requests or approvals still need to finish. Do not treat a draft, model assertion or requested command as proof that an action completed.

5. Keep useful, safe feedback

Note the installed version from Settings → General → Desktop updates, operating system and version, exact provider/model, Plan or Build, what you tried and what actually happened. If a step was not attempted, say so.

Send a report through the signed-in portal's Overview → Send feedback. The desktop's Send Early Alpha feedback action opens that portal. Reports and selected screenshots go to the support backend; remove secrets and private content yourself before submitting.

If work appears lost or cleanup is uncertain, stop further work in that trial project, preserve backups and record the visible error. Restarting does not prove child processes have stopped. Do not delete the app profile or downgrade it to troubleshoot.