Skip to main content
Updates are operator-driven in unCoded. New versions are released; you decide when to pull and restart. This page is the safe-update playbook: when, how, what to test, and how to roll back if something goes wrong.

​
Update cadence

Critical security updates — apply immediately

If a security advisory is published for a component you use, update within hours. This is the only update class without operator-discretion timing.

Bug fixes — apply within 1–2 weeks

Fixes for confirmed bugs. Apply once your normal monitoring confirms behavior matches expectation.

Feature releases — apply when needed

New features. Apply when you have a specific use for them, not because they exist.

Major versions — apply with extra care

Major version bumps may have breaking changes. Read release notes carefully; test in sub-account before production.

​
The safe update workflow

1

Read the release notes

Every release comes with notes describing changes. Read them. Understand:
  • What’s new?
  • What’s fixed?
  • What’s deprecated or breaking?
  • Any recommended operator action?
Don’t update blindly. Two minutes of reading saves hours of surprise debugging.
2

Pick a quiet moment

Avoid updates during:
  • Active drawdowns (one-thing-at-a-time discipline).
  • Major market events.
  • Times you can’t monitor for the next hour.
Best: weekend morning, low-volatility regime, you have time and attention.
3

Backup the database first

Before any update, take a fresh database backup. If something goes wrong post-update, you can restore.Most operators have daily automated backups; before an update, take an explicit “pre-update” backup with that label.
4

Optionally: kill switch ON

If the update is non-trivial (major version, multiple containers), engage kill switch first. New buying pauses; existing positions continue. Reduces variability while you update.
5

Pull the new version

Update the relevant Docker image tag. The CapRover bundle has its own update flow; manual deployments use docker-compose pull or equivalent.
6

Restart the affected container(s)

docker-compose up -d (or the CapRover-equivalent action). The container restarts on the new image.
7

Watch the logs for the first 5 minutes

Open the Logs panel. Confirm:
  • Container starts cleanly.
  • Connects to database, exchange, dependencies.
  • Begins normal evaluation cycles.
Errors during startup → investigate immediately. Don’t let bad updates run silently.
8

Test a few representative actions

Depending on what was updated:
  • TradingBot update: confirm it places a test order (let an active mode trigger naturally; don’t force).
  • Dashboard update: log in, navigate panels, confirm they render.
  • SignalsBot update: send a test webhook, confirm it processes.
  • TelegramBot update: wait for next trade-close, confirm notification fires.
9

If kill switch was engaged: re-enable

Confirm everything works first. Then flip the kill switch back off.
10

Watch for the first hour

Open the Logs panel. Watch live for any abnormalities. Most issues surface within the first hour after an update.If everything looks good after the first hour, you can step away with confidence.
11

Document the update

Operator log entry: “2026-04-15: updated TradingBot to v2.4.1. Reason: bug fix for rate-limit handling. No issues observed.”

​
What can go wrong — and how to handle it

Symptoms: Docker shows the container as “Restarting” repeatedly.Investigation:
  • Check container logs (docker logs <container>).
  • Common causes: configuration incompatibility, missing environment variables in new version, breaking schema changes.
Recovery:
  • Roll back to the previous version (revert image tag).
  • Restart with the previous image.
  • Investigate the new version’s release notes for required configuration changes.
Apply the new version only after the configuration is updated correctly.
Symptoms: container running but logs show errors on every cycle.Investigation:
  • Read the error message carefully.
  • Common: configuration value that needs migrating to new schema.
Recovery:
  • Apply the migration step from release notes.
  • Or roll back to the previous version while you sort out the migration.
Symptoms: bot is running but trade frequency, performance, or specific behavior differs from before.Investigation:
  • Read the release notes for behavior changes.
  • Some updates intentionally change behavior (e.g., new default values for parameters).
Recovery:
  • If the change is intentional and acceptable: continue.
  • If unintentional or unacceptable: configure to restore old behavior, or roll back.
Symptoms: TradingBot updated successfully, but Dashboard fails to start with new version.Investigation:
  • The new versions may have a compatibility requirement (e.g., new Dashboard requires new database schema that TradingBot creates).
Recovery:
  • Roll back the failed container only.
  • Run with the partially-updated stack until you can resolve the compatibility issue.
  • Or roll back all containers to their previous versions.
Generally: prefer compatible-version sets over running mixed versions long-term.
Symptoms: rolled back to old version, but it can’t read the new schema.Investigation:
  • Major version updates sometimes add tables/columns that are required by the new version.
  • Rolling back the container without rolling back the database leaves a stale-schema mismatch.
Recovery:
  • Restore the pre-update database backup.
  • Run with the old container against the old database schema.
  • Plan the upgrade more carefully next time, including database migration rollback strategy.

​
Rollback playbook

1

Identify the last-known-good version

The version you were running before the update. Note the image tag (e.g., uncoded/tradingbot:v2.3.5).
2

Update the image tag in your deployment configuration

docker-compose.yml or CapRover settings. Revert the tag to the last-known-good.
3

Pull the old image

docker-compose pull or equivalent. Confirms you have the old image cached.
4

If database schema changed: restore database backup

Restore the pre-update database backup. Without this step, the rolled-back container may not be able to read the new-schema database.
5

Restart the container

docker-compose up -d.
6

Verify behavior matches pre-update

Open the Logs panel. Confirm normal operation.
7

Document the rollback

Operator log entry: “2026-04-15: rolled back TradingBot to v2.3.5 due to startup failure on v2.4.0. Investigating root cause before retrying upgrade.”

​
Updating in sub-accounts first

For non-trivial updates (major versions, big feature releases): test in a sub-account before applying to your main production account.Pattern:
  1. Spin up an experimental sub-account TradingBot with the new version.
  2. Allocate small capital ($1,500–$3,000).
  3. Run for 1–2 weeks to validate behavior.
  4. Compare against your production main-account behavior — same trade rate, same win rate, same character?
  5. If yes: apply the update to your main account.
  6. If no: investigate the differences before rolling out.
This is the most cautious approach. Most operators don’t bother for minor updates; for major versions, it’s worth the extra step.

​
Update best practices

  • ✅ Read release notes before every update.
  • ✅ Pre-update database backup, every time — non-negotiable.
  • ✅ Pick quiet moments — not during drawdowns, not during volatile market events.
  • ✅ Optional kill switch ON during major updates — reduces variability.
  • ✅ Watch the logs for the first hour post-update.
  • ✅ Document every update in operator log — date, version, reason, observations.
  • ✅ Test in sub-account for major versions before main-account rollout.
  • ✅ Keep last-known-good versions documented — rollback is easier when you know what to revert to.
  • ✅ Don’t apply multiple major updates simultaneously — change one variable at a time.
  • ✅ Apply security updates immediately — that’s the only no-discretion class.
  • ✅ Don’t update in active drawdown — one stress event at a time.
  • ✅ Have a rollback plan before every update — even if you don’t end up needing it.

​
What’s next

Daily operations

The rhythms that include occasional updates.

Monitoring

Watching for post-update anomalies.

Support

For update-related issues you can’t resolve.

Connection problems

For post-update connectivity issues.

Common issues

Including post-update problems.

Risk overview

Updates are part of the operator’s risk discipline.
Last modified on May 3, 2026