Skip to main content

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.

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.

​
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.

Live trades panel

Every fill, every position, every trailing-stop activation — visible in real time. No refresh hunting; the panel updates as events happen.

Mode and trade-pair controls

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.

Bot status and kill switch

The single most important control: pause new orders immediately. Existing positions and pre-placed sell ladders continue to honor — only new buys stop.

Fulfilled orders ledger

The full history of every closed round-trip. Searchable, sortable, exportable. The same data that drives your Telegram notifications.

Tax report exports

CSV / JSON exports of your closed trades with USD→EUR currency conversion via Frankfurter ECB rates. Ready for your accountant.

Live log streaming

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.

Multi-symbol analytics

Aggregate performance across all your active pairs. See which symbols are working and which aren’t.

System health surface

Database connectivity, exchange connectivity, container heartbeats. If something is unhealthy, the Dashboard tells you immediately.

Onboarding tutorial

First-time operators get an in-product walkthrough — what each panel does, where the kill switch is, where tax exports live.

Two roles — admin and viewer

Admin has full control; viewer is read-only. Use viewer for trusted accountability without giving up operator authority.

​
Two roles — admin and viewer

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).
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.
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.

​
What you can do from the Dashboard

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.
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.
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.
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.
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.
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.
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.
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.
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.
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?”

​
Operator routines built around the Dashboard

The Dashboard supports several rhythms — daily, weekly, monthly, yearly. Here’s how operators typically structure their interaction.
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.”
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.
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?
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?
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.

​
What the Dashboard does NOT do

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.

​
The single internet-exposed surface (besides webhooks)

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.

​
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.
SurfaceReads fromWrites to
Live trades panelTrade tables (live), TradingBot logs (streamed)—
Modes panelMode-config tableSame — operator edits land here
Trade pairs panelActive-pair configSame — operator edits land here
Bot status / kill switchBot-status tableSame — flag toggles land here
Fulfilled orders ledgerClosed-trade table— (read-only)
Tax reportClosed-trade table + Frankfurter APIGenerates a CSV/JSON for download (no DB write)
UI settingsUI-settings tableSame — 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

Always front the Dashboard with a reverse proxy that terminates TLS. Caddy is the simplest option:
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).
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.
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:
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.
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.
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.

​
Operational footprint

Resource cost

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.

Network calls

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.

Failure mode

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.

Startup time

Boots in seconds. Validates database connectivity, applies any pending schema changes, then begins serving the SPA and API endpoints.

Concurrent sessions

Supports many concurrent admin and viewer sessions. Most operators run 1–3 simultaneous sessions (laptop, phone, partner-witness). No upper limit at typical scale.

Update cadence

Updates are operator-driven. Pull the latest container, restart, re-login. Backward compatibility is honored across minor versions.

​
Common questions

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

​
Best practices

  • ✅ 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.

​
What’s next

TradingBot

The execution engine your Dashboard controls.

Quickstart

The full setup, including TLS reverse proxy and Dashboard onboarding.

Architecture

Where the Dashboard sits in the overall system, and why.

Security Philosophy

Why the Dashboard is one of only two internet-exposed surfaces.

Tax Export

Detailed walkthrough of the tax report and how to use it.

Troubleshooting

Every common Dashboard issue and recovery procedure.
Last modified on May 3, 2026