> ## Documentation Index
> Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Dashboard — Your Operator Cockpit

> The single web interface where you see what the bots are doing, control modes, manage trade pairs, review trades, and pull tax reports. The cockpit you use to fly the rest of the stack.

<Info>
  **The Dashboard is where you actually run unCoded.** Every other module is a worker — the TradingBot executes, the TelegramBot notifies, the SignalEditor authors, the SignalsBot receives, the Backtester simulates. The Dashboard is the cockpit you use to see and control all of them.
</Info>

## What the Dashboard does for you

The Dashboard is your **single, authenticated control surface**. You don't SSH into the server. You don't edit JSON files by hand. You don't query the database with `psql`. You open the Dashboard in your browser, log in, and everything you need to operate your bots is one click away.

You see live trades as they fill. You toggle the kill switch. You enable or disable modes. You add or remove trade pairs. You review fulfilled orders. You pull tax reports. You stream live logs from the TradingBot. You configure UI preferences. All in one place, behind your password, on TLS.

For most operators, the Dashboard is the surface they spend the most time with. The TradingBot runs by itself; you check on it via the Dashboard.

<CardGroup cols={2}>
  <Card title="Live trades panel" icon="chart-line">
    Every fill, every position, every trailing-stop activation — visible in real time. No refresh hunting; the panel updates as events happen.
  </Card>

  <Card title="Mode and trade-pair controls" icon="sliders">
    Add a symbol, remove a symbol, change a mode's parameters, switch a pair from one mode to another. Every change persists to the local database within milliseconds.
  </Card>

  <Card title="Bot status and kill switch" icon="power-off">
    The single most important control: pause new orders immediately. Existing positions and pre-placed sell ladders continue to honor — only new buys stop.
  </Card>

  <Card title="Fulfilled orders ledger" icon="list-check">
    The full history of every closed round-trip. Searchable, sortable, exportable. The same data that drives your Telegram notifications.
  </Card>

  <Card title="Tax report exports" icon="file-invoice">
    CSV / JSON exports of your closed trades with USD→EUR currency conversion via Frankfurter ECB rates. Ready for your accountant.
  </Card>

  <Card title="Live log streaming" icon="terminal">
    Stream the TradingBot's container logs to your browser via Server-Sent Events. Watch live as orders are placed, fills are processed, errors are surfaced.
  </Card>

  <Card title="Multi-symbol analytics" icon="chart-bar">
    Aggregate performance across all your active pairs. See which symbols are working and which aren't.
  </Card>

  <Card title="System health surface" icon="heart-pulse">
    Database connectivity, exchange connectivity, container heartbeats. If something is unhealthy, the Dashboard tells you immediately.
  </Card>

  <Card title="Onboarding tutorial" icon="graduation-cap">
    First-time operators get an in-product walkthrough — what each panel does, where the kill switch is, where tax exports live.
  </Card>

  <Card title="Two roles — admin and viewer" icon="user-shield">
    Admin has full control; viewer is read-only. Use viewer for trusted accountability without giving up operator authority.
  </Card>
</CardGroup>

## Two roles — admin and viewer

<AccordionGroup>
  <Accordion title="Admin — full control" icon="user-shield">
    The admin role can do everything: change modes, edit trade pairs, toggle the kill switch, generate tax reports, change UI settings. Most operators have one admin password — their own.

    Use admin credentials only on devices you control. Rotate the admin password after any incident (e.g., losing a phone or laptop).
  </Accordion>

  <Accordion title="Viewer — read-only witness" icon="eye">
    The viewer role can see panels but cannot make changes. No Settings, no Tax export, no kill-switch toggle.

    Use viewer credentials when you want a partner, accountant, or trusted reviewer to see your bot's activity without giving them control. The viewer password is separate from the admin password — losing the viewer password does not compromise your bot.
  </Accordion>
</AccordionGroup>

<Tip>
  **Use the viewer role for accountability without giving up control.** A spouse, a financial partner, or your accountant can be a viewer — they see exactly what's happening and can audit your activity without being able to change anything. This is one of the most useful patterns in operating a bot you'd otherwise feel solitary about.
</Tip>

## What you can do from the Dashboard

<AccordionGroup>
  <Accordion title="Toggle the kill switch" icon="power-off">
    The kill switch sets a single flag in your local database that the TradingBot reads on every cycle. When set, the TradingBot **stops placing new buy orders**. Already-open positions, pre-placed sell-ladder rungs, and trailing stops **continue to honor** — they live on the exchange itself, not on your VPS.

    This is the most important operator control. Use it when you're worried, when there's news you don't understand, when the market is doing something you didn't expect, or when you simply want to step back and observe.

    Toggling back on is just as fast — flip the switch, and on the next configuration poll the TradingBot resumes normal operation.
  </Accordion>

  <Accordion title="Manage trade pairs" icon="coins">
    Add a symbol to your active set, remove one, change which mode a pair is assigned to. Each change persists to the local database and is picked up by the TradingBot within seconds.

    The Dashboard validates pair entries before saving — checking that the symbol matches your exchange's naming convention and that the assigned mode exists. Bad entries are rejected at the form, not silently mis-traded.
  </Accordion>

  <Accordion title="Edit modes" icon="sliders">
    Each pre-built mode has a handful of parameters: buy-ladder shape, sell-ladder rungs, trailing-stop activation distance, hard stop-loss, time-decay sell logic. Edit any of these from the Modes panel.

    Edits to a mode apply to **every active pair using that mode**. If `BTCUSDT`, `ETHUSDT`, and `SOLUSDT` are all on Mode 4, an edit to Mode 4 changes all three. To customize per-pair, assign each pair to a different mode and edit that one independently.
  </Accordion>

  <Accordion title="Review fulfilled orders" icon="list-check">
    The fulfilled-orders ledger shows every closed round-trip: buy time and price, sell time and price, profit, profit percentage, running totals. The same data that drives your Telegram notifications, but in a sortable, filterable, exportable view.

    Sort by P\&L to find your best and worst trades. Filter by symbol, by date range, by mode. Export as CSV for your records.
  </Accordion>

  <Accordion title="Generate tax reports" icon="file-invoice">
    The Tax Report panel exports your closed trades for tax-year reporting. Each trade is exported with:

    * Buy and sell timestamps
    * Buy and sell prices in USD
    * **EUR equivalents** at the exact exchange rate on the relevant date (sourced from the European Central Bank via the Frankfurter API)
    * Realized P\&L in both USD and EUR
    * The symbol and the mode that ran the trade

    Output formats: CSV (for spreadsheet review) and JSON (for programmatic processing). Your accountant gets a clean, audit-ready dataset.
  </Accordion>

  <Accordion title="Stream live logs" icon="terminal">
    The Logs panel opens a live stream of the TradingBot's container output. You see orders being placed, fills being processed, errors being surfaced — all in real time, without SSH.

    Useful for debugging strange behavior ("why didn't this trade fire?") and for confidence checks ("is the bot actually doing anything right now?"). The stream is read-only — nothing typed in the Logs panel changes the bot's behavior.
  </Accordion>

  <Accordion title="Configure UI preferences" icon="palette">
    Layout, theme, panel ordering — operator preference settings persist to the database keyed to your role. Your dashboard looks the same on any device you log in from.
  </Accordion>

  <Accordion title="Run the onboarding tutorial" icon="graduation-cap">
    First-time operators are walked through the Dashboard's panels via an in-product tutorial — what each panel does, what the kill switch is, where to find tax exports. The tutorial state is persisted; once completed, it doesn't pop up again.
  </Accordion>

  <Accordion title="Inspect connection state" icon="signal">
    The Dashboard surfaces the health of every component: TradingBot connection to the exchange, database connectivity, TelegramBot status, SignalEditor / SignalsBot reachability. If anything is degraded, you see it immediately on the main panel.
  </Accordion>

  <Accordion title="Inspect mode-specific analytics" icon="chart-bar">
    Beyond per-trade ledgers, the Dashboard aggregates performance per mode and per pair. Quickly answer: "is BasicMode on `BTCUSDT` outperforming or underperforming my expectation?" "Are my newer pairs pulling their weight?"
  </Accordion>
</AccordionGroup>

## Operator routines built around the Dashboard

The Dashboard supports several rhythms — daily, weekly, monthly, yearly. Here's how operators typically structure their interaction.

<AccordionGroup>
  <Accordion title="Daily — 5-minute health check" icon="calendar-day">
    Most operators do a daily 5-minute scan:

    * Open the main panel. Confirm the kill switch is in the expected state.
    * Glance at the Live Trades panel — anything unusual? Any positions held abnormally long?
    * Glance at the connection-state indicators — all green?
    * Skim the day's closed trades — totals match Telegram? Any anomalies?

    If everything looks normal, log out. The whole exercise takes 2–5 minutes. The goal is not to make decisions every day; it's to confirm "the bot is doing what I expect."
  </Accordion>

  <Accordion title="Weekly — 30-minute structured review" icon="calendar-week">
    Once a week, do a more substantial review:

    * Pull the week's analytics. Compare against last week and against your monthly running average.
    * Identify your worst trade of the week. Open the order detail. Was the mode behaving as designed, or was there an anomaly?
    * Identify your best trade. Was it the mode hitting expected rungs, or an unusually large move?
    * Check the Logs panel for any recurring warnings or errors.
    * Confirm all expected pairs have traded — a pair that hasn't closed a round-trip in a week is a flag worth investigating.
    * Decide: any operator action this week? New pair to add? Mode parameter to tune? Pair to retire?

    Weekly reviews are where operator skill develops. The decisions you make here, deliberately and with data, compound over months.
  </Accordion>

  <Accordion title="Monthly — tax export + capital review" icon="calendar">
    At month-end:

    * Pull the Tax Report for the month. Archive to your designated folder.
    * Cross-check the month's total against the Telegram running total at month-end.
    * Review capital allocation. Is each mode's allocated capital still appropriate? Should you scale up or down?
    * Review reserve. Is the `~50%` of trading capital still intact? If not, what eroded it?
    * Plan: any structural change for next month? New venue? New mode trial?
  </Accordion>

  <Accordion title="Yearly — full audit + accountant handoff" icon="calendar-days">
    At year-end:

    * Pull the full-year Tax Report.
    * Verify against the sum of monthly archives.
    * Verify against the Telegram running total at year-end.
    * All three should agree. Investigate any discrepancy.
    * Send the report to your accountant.
    * Conduct a strategic review: is the bot doing what you intended? Should the next year's setup look different?
  </Accordion>

  <Accordion title="Crisis — kill switch and recovery" icon="bolt">
    When something is going wrong (market shock, news, unexpected bot behaviour):

    * **Step 1**: kill switch ON. Use the Dashboard's main panel button. Within seconds, no new buy orders.
    * **Step 2**: open the Logs panel. Watch for recent errors or unusual messages.
    * **Step 3**: open the Live Trades panel. Inspect open positions. Are any in surprising states?
    * **Step 4**: if necessary, manually close positions on the exchange itself.
    * **Step 5**: when the situation is clear, decide: kill switch back ON or stay paused?
    * **Step 6**: log the incident in your operator notes. Include what triggered the response, what you did, what you'd do differently.

    Don't be cavalier with the kill switch — but don't be hesitant either. It's there to be used.
  </Accordion>
</AccordionGroup>

## What the Dashboard does NOT do

<Warning>
  **The Dashboard is the operator interface — not the trading layer.**

  * ❌ The Dashboard does not place orders. It writes configuration to the local database; the TradingBot acts on configuration.
  * ❌ The Dashboard does not hold your exchange API keys. The TradingBot does.
  * ❌ The Dashboard does not author strategies. That's the SignalEditor.
  * ❌ The Dashboard does not receive signals. That's the SignalsBot.
  * ❌ The Dashboard does not send Telegram notifications. That's the TelegramBot.
  * ❌ The Dashboard does not run scheduled jobs. The SignalEditor's scheduler is the only periodic job runner.
  * ❌ The Dashboard does not subscribe to your exchange's WebSocket streams from the backend. (The frontend may open browser-side WebSockets for chart panels — that's an operator's browser, not your VPS.)
  * ❌ The Dashboard does not verify your tax filings. It exports the data; you (or your accountant) file the return.

  This separation is intentional. If the Dashboard is briefly unreachable (e.g., during a deploy), your trading is unaffected. The TradingBot continues running on the configuration it last read.
</Warning>

## The single internet-exposed surface (besides webhooks)

<Warning>
  **The Dashboard is one of only two components that get internet exposure** (the other is the SignalsBot, if you use webhooks). Everything else lives on your VPS's internal Docker network.

  This means:

  * ✅ **Always put the Dashboard behind a TLS reverse proxy.** Caddy, nginx-proxy-manager, or Traefik all work. Never expose the raw HTTP port.
  * ✅ **Use a strong admin password.** The HMAC-signed session cookie is reasonably secure, but the password is the front door — make it long and random.
  * ✅ **Rotate after any device loss.** A laptop or phone going missing is a reason to rotate immediately.
  * ✅ **Consider IP allow-listing** at the reverse-proxy level if you only ever log in from a couple of locations.
  * ✅ **Use viewer credentials for shared access.** Never share your admin password.
  * ✅ **Watch the audit log** for unusual login attempts.
</Warning>

## The data the Dashboard sees

The Dashboard reads and writes the same local PostgreSQL database the TradingBot uses. There is no separate Dashboard database, no proxy layer, no eventually-consistent cache — what the Dashboard shows is what the TradingBot is acting on.

| Surface                      | Reads from                                      | Writes to                                       |
| ---------------------------- | ----------------------------------------------- | ----------------------------------------------- |
| **Live trades panel**        | Trade tables (live), TradingBot logs (streamed) | —                                               |
| **Modes panel**              | Mode-config table                               | Same — operator edits land here                 |
| **Trade pairs panel**        | Active-pair config                              | Same — operator edits land here                 |
| **Bot status / kill switch** | Bot-status table                                | Same — flag toggles land here                   |
| **Fulfilled orders ledger**  | Closed-trade table                              | — (read-only)                                   |
| **Tax report**               | Closed-trade table + Frankfurter API            | Generates a CSV/JSON for download (no DB write) |
| **UI settings**              | UI-settings table                               | Same — preferences land here                    |

This is what makes the Dashboard fast and authoritative. No syncing delay. No "the database thinks one thing, the dashboard shows another."

## Securing the Dashboard

<AccordionGroup>
  <Accordion title="Reverse proxy + TLS — non-negotiable" icon="lock">
    Always front the Dashboard with a reverse proxy that terminates TLS. Caddy is the simplest option:

    ```text theme={null}
    dashboard.yourdomain.com {
      reverse_proxy dashboard:80
    }
    ```

    Caddy auto-acquires Let's Encrypt certificates on startup. Renewal is automatic. Most operators get this set up once and never touch it again.

    Alternatives: nginx-proxy-manager (GUI-driven), Traefik (advanced features), Cloudflare Tunnel (zero-port-exposure).
  </Accordion>

  <Accordion title="Strong admin password" icon="key">
    The admin password is the front door. Make it long (`20+` characters) and random. Use a password manager.

    Common pattern: generate with `openssl rand -base64 24`. Save in a password manager. Never commit to a Git repo, never share via plaintext channel.
  </Accordion>

  <Accordion title="IP allow-listing at the proxy" icon="filter">
    If you only ever log in from a small number of locations (home IP, work IP, VPN exit IP), allow-list those at the reverse-proxy level. This adds a strong second factor — even with the password, an attacker has to be on an allow-listed IP.

    Caddy example:

    ```text theme={null}
    dashboard.yourdomain.com {
      @allowed remote_ip 203.0.113.0/24 198.51.100.5
      handle @allowed {
        reverse_proxy dashboard:80
      }
      handle {
        respond 403
      }
    }
    ```

    Caveat: if your home IP is dynamic, this becomes operationally annoying. Consider a static IP or a VPN exit you control.
  </Accordion>

  <Accordion title="2FA via reverse proxy" icon="shield-halved">
    The Dashboard's primary auth is password-based. For a stronger second factor, the right pattern is to add 2FA at the reverse-proxy layer:

    * **Authelia**: open-source self-hosted 2FA proxy. Strong choice for security-conscious operators.
    * **Cloudflare Access**: managed 2FA proxy with email/2FA prompts. Simple if you already use Cloudflare.
    * **Tailscale**: not 2FA per se, but mesh-VPN that means only your devices can reach the Dashboard. Powerful for some setups.

    Pick one that fits your operational style. Don't run without one if you're remotely concerned about credential theft.
  </Accordion>

  <Accordion title="Viewer-role for partners" icon="user-group">
    Set the viewer password to a separate, strong value. Share it with one trusted person — your spouse, your accountant, your business partner. They see panels but cannot change anything.

    The viewer's worst-case is "they can read your trade history" — same threat model as the Telegram chat. Acceptable for most relationships.
  </Accordion>

  <Accordion title="Session and cookie hygiene" icon="cookie-bite">
    The Dashboard's session cookie has a `7-day` TTL. Log out manually after sessions on shared devices. Rotate the admin password if you suspect compromise; existing sessions invalidate.

    Avoid logging in from public Wi-Fi without a VPN. The TLS protects the session in transit but the local network can still see DNS lookups.
  </Accordion>
</AccordionGroup>

## Operational footprint

<CardGroup cols={2}>
  <Card title="Resource cost" icon="microchip">
    The Dashboard backend is a small HTTP server (`~75 KB` of source). Frontend is a single-page web app served as static assets. Total: a few hundred MB of RAM, sub-percent CPU at idle.
  </Card>

  <Card title="Network calls" icon="globe">
    Inbound on the configured HTTPS port for browser access. Outbound to your exchange's public REST API (read-only price/kline data) and to Frankfurter (for tax-report currency conversion). No outbound writes to anything.
  </Card>

  <Card title="Failure mode" icon="triangle-exclamation">
    If the Dashboard crashes, **trading is unaffected**. The TradingBot continues running. You lose your control surface temporarily — bring the container back up, log in, resume.
  </Card>

  <Card title="Startup time" icon="stopwatch">
    Boots in seconds. Validates database connectivity, applies any pending schema changes, then begins serving the SPA and API endpoints.
  </Card>

  <Card title="Concurrent sessions" icon="users">
    Supports many concurrent admin and viewer sessions. Most operators run 1–3 simultaneous sessions (laptop, phone, partner-witness). No upper limit at typical scale.
  </Card>

  <Card title="Update cadence" icon="rotate">
    Updates are operator-driven. Pull the latest container, restart, re-login. Backward compatibility is honored across minor versions.
  </Card>
</CardGroup>

## Common questions

<AccordionGroup>
  <Accordion title="Can I run the Dashboard on a different VPS than the TradingBot?" icon="circle-question">
    **Technically yes**, if both can reach the same database. In practice, almost no operator does this — the One-Click bundle co-locates everything for simplicity, and there's no functional benefit to splitting hosts at this scale.

    The exception is operators running multiple TradingBots across multiple VPSs (one per exchange, geographically distributed). In that pattern, a single shared Dashboard reading from the shared database makes sense.
  </Accordion>

  <Accordion title="What about two-factor authentication?" icon="circle-question">
    The Dashboard's primary auth is password-based with a session cookie (`7-day` TTL). If you want a stronger second factor, the right pattern is to put the Dashboard behind a reverse proxy that handles 2FA itself (Authelia, Cloudflare Access, Tailscale, etc.).

    Adding 2FA at the application layer is on the longer-term roadmap; for now the proxy-layer approach is widely supported and gives you choice over which 2FA provider to use.
  </Accordion>

  <Accordion title="How do I add a viewer for my partner?" icon="circle-question">
    Set the viewer password environment variable on the Dashboard container. Restart the container. Your partner logs in with the viewer password and sees read-only panels — Settings and Tax are hidden, kill switch is greyed out.

    Use a separate, distinct password from your admin password. Treat them as independent credentials.
  </Accordion>

  <Accordion title="Can multiple operators log in simultaneously?" icon="circle-question">
    **Yes.** The Dashboard supports multiple concurrent sessions on the same role. If two admin sessions edit the same mode at the same time, the second write wins (last-writer-wins is the database default). This is rare in practice — most operators have one admin actively working.
  </Accordion>

  <Accordion title="Why is the live-log panel useful?" icon="circle-question">
    Three reasons.

    **Confidence.** When you start the bot for the first time, watching the log stream confirms "yes, this is alive, it's connected to the exchange, it's evaluating pairs."

    **Debugging.** If a trade didn't fire when you expected, the log usually says why — "min notional below floor," "rate limit cooldown," "exchange returned -2010." You see this without SSH.

    **Validation.** Operators who occasionally tail the log build intuition for what "normal" looks like — and notice when something deviates.

    The log stream is read-only — nothing typed in the panel changes the bot's behavior.
  </Accordion>

  <Accordion title="What does the tax report actually contain?" icon="circle-question">
    For each closed trade in the selected period:

    * Buy and sell timestamps (in your timezone)
    * Buy and sell prices in USD (8-decimal precision)
    * EUR equivalents at the **exchange rate from the European Central Bank** (Frankfurter API) on the relevant date
    * Realized P\&L in both USD and EUR
    * Symbol and mode

    Format: CSV (spreadsheet-friendly) or JSON (programmatic). Your accountant gets a clean dataset that maps directly onto most jurisdictions' capital-gains reporting requirements.

    **Important**: unCoded does not file your taxes for you. The dashboard exports the data; you (or your accountant) file the return.
  </Accordion>

  <Accordion title="Can I restyle the Dashboard?" icon="circle-question">
    Theme and layout preferences are operator-configurable. The frontend is shipped as built static assets — to deeply customize the visuals (e.g., reskin for a partnership), you'd rebuild the frontend from source. This is rare; most operators run the default theme.
  </Accordion>

  <Accordion title="Do I need the Dashboard if I just want to run a pre-built mode?" icon="circle-question">
    **Strongly recommended.** Technically, you could configure the TradingBot via direct database edits and never log into a Dashboard, but you'd lose the kill switch's UI, the live log stream, the tax export, the mode editor, the live trades panel, and the onboarding tutorial.

    The Dashboard is part of the One-Click bundle precisely because operating a bot without a control surface is uncomfortable. Always run it.
  </Accordion>

  <Accordion title="Can I use the Dashboard on mobile?" icon="circle-question">
    The Dashboard's frontend is responsive — usable on a phone in a pinch. The kill switch is reachable, the live trades panel is readable, the analytics panels render.

    For day-to-day administration (adding pairs, editing modes), a laptop or desktop is more comfortable. For "I'm in a coffee shop and need to flip the kill switch," mobile is fine.
  </Accordion>

  <Accordion title="What if the Dashboard goes down mid-session?" icon="circle-question">
    Your trading is unaffected — the TradingBot runs on its current configuration, which is in the database. You lose the control surface temporarily.

    Most Dashboard outages are sub-minute (Docker restart, brief crash). The reverse proxy will return a `502` until the container is back. Wait, refresh, log back in, resume.

    For actual recovery scenarios, the Dashboard's data is fully recoverable from the database — there's no Dashboard-specific state to back up beyond what's already in your database backups.
  </Accordion>

  <Accordion title="Can I expose the Dashboard publicly with just a password?" icon="circle-question">
    **Yes — but layer at least one extra control.** A password-only public exposure is a bait target. Add at least:

    * Strong password (`20+` chars, random)
    * IP allow-list at the reverse proxy (if you have stable IPs)
    * 2FA at the proxy layer (Authelia, Cloudflare Access)

    Most operators use 1–2 of these layers. The most paranoid use all three plus a VPN.
  </Accordion>

  <Accordion title="What logs does the Dashboard keep?" icon="circle-question">
    The Dashboard logs login attempts (success/failure with IP), configuration changes (admin actions), and any internal errors. The log is the same one the Logs panel streams.

    For long-term audit, forward the logs to your preferred sink (Loki, Elasticsearch, plain file rotation). Compliance-conscious operators keep at least a year of dashboard logs.
  </Accordion>
</AccordionGroup>

## Best practices

<Tip>
  * ✅ **Always run behind TLS** — never expose the Dashboard's raw HTTP port to the public internet.
  * ✅ **Use a strong admin password** — generate it with a password manager, store it there.
  * ✅ **Set up a viewer password** for trusted reviewers — partner, accountant, advisor.
  * ✅ **Bookmark the kill-switch button location** — speed of access matters when something is going wrong.
  * ✅ **Open the live trades panel daily** — even if you trust the bot, scanning the stream builds intuition.
  * ✅ **Pull a tax report at year-end** — early enough to give your accountant time, late enough that the trades are settled.
  * ✅ **Watch the log stream during the first hour after any change** — new mode, new pair, new strategy. Catches misconfigurations cheap.
  * ✅ **Rotate passwords after any device loss** — phone gone missing is a reason to rotate immediately.
  * ✅ **Add 2FA at the proxy layer** if you're at all concerned about credential theft.
  * ✅ **IP allow-list when you can** — strong second factor that's transparent in normal use.
  * ✅ **Forward dashboard logs to a long-term sink** for compliance and post-incident analysis.
  * ✅ **Document your daily/weekly/monthly routines** in a personal runbook — consistency compounds.
  * ✅ **Review failed-login attempts weekly** — unfamiliar IP attempting your password is a flag.
</Tip>

## What's next

<CardGroup cols={2}>
  <Card title="TradingBot" icon="robot" href="/modules/tradingbot">
    The execution engine your Dashboard controls.
  </Card>

  <Card title="Quickstart" icon="forward" href="/quickstart">
    The full setup, including TLS reverse proxy and Dashboard onboarding.
  </Card>

  <Card title="Architecture" icon="server" href="/concepts/architecture">
    Where the Dashboard sits in the overall system, and why.
  </Card>

  <Card title="Security Philosophy" icon="shield" href="/about/security-philosophy">
    Why the Dashboard is one of only two internet-exposed surfaces.
  </Card>

  <Card title="Tax Export" icon="file-invoice" href="/operations/tax-export">
    Detailed walkthrough of the tax report and how to use it.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/troubleshooting/common-issues">
    Every common Dashboard issue and recovery procedure.
  </Card>
</CardGroup>