mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-06 02:48:25 +00:00
a8599a924f
The primary install flow is now to start the server, complete setup in a browser-based wizard, and restart. fabro install is retained as the headless CLI-only alternative. - Auto-open the install URL in the user's browser when fabro server start enters install mode; print a manual-open fallback when open::that fails - Rewrite install.md so agents drive the full start → wait → restart loop - Retarget install.sh Y/n prompt from fabro install to fabro server start - Update README, quick-start, deploy-server, cli reference, and marketing captions to point at fabro server start as the next step after download - Add troubleshooting entries for "wizard didn't open" and "server exited after wizard" Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
42 lines
2.5 KiB
Text
42 lines
2.5 KiB
Text
---
|
|
title: "Troubleshooting"
|
|
description: "Diagnosing and resolving common issues with Fabro"
|
|
---
|
|
|
|
## `fabro doctor`
|
|
|
|
The `fabro doctor` command validates your installation:
|
|
|
|
```bash
|
|
fabro doctor # Local config checks + live server diagnostics
|
|
fabro doctor --verbose # Show detailed output for each check
|
|
fabro doctor --server https://fabro.example.com/api/v1
|
|
```
|
|
|
|
It checks:
|
|
- Local user config and storage directory health
|
|
- Server-reported LLM provider connectivity
|
|
- GitHub App, sandbox, and Brave Search credentials
|
|
- Server authentication and crypto configuration
|
|
|
|
## Common issues
|
|
|
|
**Install wizard didn't open in my browser** — `fabro server start` prints the install URL to stderr before attempting to open it. Copy that URL into your browser manually. Auto-open fails on headless Linux hosts, inside most containers, and over SSH sessions without a display.
|
|
|
|
**Server exited after I finished the install wizard** — Expected. The server writes `~/.fabro/settings.toml` and exits cleanly at the end of the wizard. Start it again with `fabro server start` to boot in configured mode, or run it under a supervisor with a restart policy (for example docker-compose `restart: unless-stopped`, systemd, or Railway's restart-on-exit) so the second start happens automatically.
|
|
|
|
**"No API key configured"** — Set at least one provider key with `fabro provider login` or `fabro secret set`, or export it in the server process environment. Run `fabro doctor` to verify connectivity.
|
|
|
|
**Stall watchdog timeouts** — If runs are cancelled unexpectedly, the agent may be stuck or the LLM provider may be slow. Check `FABRO_LOG=debug` output for `Agent.LlmRetry` events. Increase `stall_timeout` in the graph if needed, or add [fallback providers](/core-concepts/models) to handle outages.
|
|
|
|
**Sandbox creation failures** — For Docker: ensure the Docker daemon is running and the configured image exists. For Daytona: verify `DAYTONA_API_KEY` is set and the `gh` CLI is authenticated. For Exe: verify your SSH keys are configured for `exe.dev` and that `ssh exe.dev` connects successfully.
|
|
|
|
**Port already in use** — Change the port with `fabro server start --port 3001` or stop the conflicting process.
|
|
|
|
**SSE streams disconnecting** — If using a reverse proxy, ensure buffering is disabled and the connection timeout is long enough for workflow runs. See the [DigitalOcean reverse-proxy example](/administration/deploy-digital-ocean).
|
|
|
|
**Run config validation errors** — Use `fabro preflight` to validate without executing:
|
|
|
|
```bash
|
|
fabro preflight run.toml
|
|
```
|